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ABSTRACT 


Organizational  Maintenance  Activities  (OMAs)  within  the  Naval  Aviation  Mainte¬ 
nance  organization  do  not  have  an  adequate  information  system  (IS).  This  seriously 
degrades  their  ability  to  efficiently  and  effectively  manage  their  aircraft,  equipment,  and 
personnel.  Information  systems  to  support  both  Naval  Air  Systems  Command 
(NAVAIR)  and  the  operational  chain  of  command  include  Naval  Aviation  Depot  In¬ 
formation  System  (NADIS),  Naval  Air  Logistics  Data  Analysis  (NALDA),  and  Naval 
Aviation  Logistics  Command  Management  Information  System  (NALCOMIS).  The 
portion  of  NALCOMIS  intended  to  support  OMAs  is  not  scheduled  to  be  fully  imple¬ 
mented  until  1999.  Decisions  made  at  OMAs  have  an  immediate  impact  on  force  read¬ 
iness  and  mission  capability.  Moreover,  the  largest  unfulfilled  need  for  information 
systems  in  the  naval  aviation  community  is  at  the  OMAs.  This  thesis  examines_the 
history  ofTS  in  Aviation  Maintenance,  analyzes  why  OMAs  lack  adequate' ISs,  and  of¬ 
fers  a  solution  within  the  current  technological  capabilities  of  the  aviation  maintenance 
community.  The  potential  improvement  in  operational  readiness,  avoidance  of  increased 


maintenance  and  personnel  costs,  improved  decision  making,  and  accuracy  of  informa- 
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I.  INTRODUCTION 


A.  BACKGROUND 

Over  the  years  a  large  organization  has  developed  in  the  Navy  dedicated  to 
procuring  aircraft,  repairing  those  aircraft,  ensuring  the  parts  and  associated 
aeronautical  equipment  are  purchased  to  repair  them,  and  managing  the  repair 
effort.  Today,  the  Naval  Air  Systems  Command  (NAVAIR)  encompasses  every 
aspect  of  aviation  in  the  Navy,  from  research  and  development,  through  pro¬ 
curement,  to  maintenance  and  servicing.  NAVAIR,  the  Naval  Supply  Systems 
Command  (NAVSUP),  and  various  operational  and  administrative  commanders 
constantly  interact  to  ensure  that  operational  readiness  standards  are  designed 
into  and  maintained  throughout  the  life  cycle  of  each  aircraft  weapons  system. 
Measuring  and  tracking  operational  readiness  requires  data  and  information 
about  maintenance,  logistics,  and  operations.  Maintenance  information  includes 
data  about  the  status  of  the  aircraft  and  about  what  maintenance  has  been  per¬ 
formed  to  achieve  that  status.  Logistics  information  includes  data  about  the  lo¬ 
cation  and  estimated  time  of  arrival  of  parts,  personnel,  and  equipment. 
Operations  information  includes  data  about  the  flights  flown  and  the  missions 
performed  by  those  units.  This  information  forms  the  basis  of  future  procure¬ 
ments  (e.g.,  aircraft,  spare  parts,  and  people),  current  repair  policies  (i.e.,  fix  it 
or  scrap  it),  parts  inventory  stocking  (i.e.,  how  many  and  where),  as  well  as  which 
unit  or  aircraft  to  use  for  which  mission  and  whom  to  assign  to  a  particular 
maintenance  action. 
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All  aspects  of  Naval  Aviation  Maintenance  are  governed  by  the  Naval  Avi¬ 
ation  Maintenance  Program  (NAMP)  which  was  established  by  the  Chief  of 
Naval  Operations  (CNO)  on  26  October  1959.  The  details  of  this  program  are 
promulgated  in  OPNAV1NST  4790.2E  [Ref.  1]  which  specifies  the  "policies,  pro¬ 
cedures,  and  responsibilities  for  the  conduct  of  the  NAMP  at  all  levels  of  main¬ 
tenance  throughout  naval  aviation." 

The  NAMP  is  a  dynamic  program  intended  to  take  advantage  of  improve¬ 
ments  in  both  technological  and  management  methods  and  techniques.  Infor¬ 
mation  system  technology  has  benefited  from  improvements  in  computer 
hardware  technology,  and  Aviation  Maintenance  has  taken  advantage  of  those 
improvements  to  increase  the  capabilities  of  its  hardware.  However,  information 
systems  are  not  just  hardware,  but  software  and  people  as  well.  Software  devel¬ 
opment  is  the  acknowledged  weak  link  in  information  systems  development. 
"Computer  hardware  productivity  continues  to  increase  by  leaps  and  bounds, 
while  software  productivity  seems  to  be  barely  holding  its  own."  [Ref.  2:  p.  43] 
This  has  led  to  an  estimated  backlog  of  three  to  five  years  [Ref.  3:  p.  323]  which 
DeMarco  says  is  "the  fault  of  inflated  and  unreasonable  expectations."  [Ref.  4:  p. 
4]  Naval  Aviation  has  fallen  victim  to  the  same  inflated  expectations  and  poor 
software  production  problems  described  by  Boehm  and  DeMarco.  The  most  de¬ 
ficient  aspect  has  been  in  the  information  system  capability  and  support  of  Or¬ 
ganizational  Maintenance  Activities  (OMAs).  OMAs  are  typically  limited  to  a 
few  micro  computers,  some  office  automation  software  such  as  wordprocessing, 
spreadsheet  and  database  management,  and  maybe  a  terminal  linking  them  to 
their  immediate  support  activities. 
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B.  OBJECTIVES 


The  objective  of  this  thesis  is  to  start  the  process  of  providing  OMAs  with  a 
much  needed  information  system  (IS).  As  with  all  such  systems,  the  first  step  is 
a  plan  derived  from  an  analysis  of  the  information  requirements  of  the  OMAs. 
The  key  goal  of  the  system  is  to  provide  the  information  required  to  the  people 
who  require  it  when  they  require  it  and  in  such  a  form  that  they  can  and  will  use 
it.  It  is  more  than  just  automation.  It  is  a  blueprint  for  long  and  short  range 
system  development.  It  will  allow  system  growth  to  be  managed  rather  than 
merely  accepted  by  default.  Current  and  planned  information  systems  are  in¬ 
cluded  where  warranted  or  dictated  by  NAVAIR  policy.  Several  issues  will  be 
addressed,  including: 

•  What  are  the  strategic  goals  and  missions  of  OMAs?, 

•  What  information  is  required  to  achieve  those  goals?, 

•  Which,  if  any,  current  or  planned  systems  should  be  included?, 

•  What  interfaces  with  other  systems  should  h  included?, 

•  Should  an  Expert  System  (or  several)  be  an  integral  part  of  the  plan?, 

•  Should  a  Decision  Support  System  (or  several)  be  an  integral  part  of  the 
plan?, 

•  Who,  i.e.  what  activity,  should  coordinate  implementing  this  plan?. 

•  Who  should  be  tasked  with  actual  development?, 

•  Who  should  be  tasked  with  post  deployment  support  of  the  system?,  and 

•  How  will  this  plan  be  funded? 

C.  SCOPE,  LIMITATIONS  AND  ASSUMPTIONS 

The  proposed  system  is  so  large  that  this  thesis  will  be  able  to  address  only 
design  issues.  The  plan  will  include  a  proposal  for  the  subsequent  steps  necessary 
for  full  implementation. 
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Descriptions  of  OMAs  are  based  on  the  author's  personal  experience  at  two 
types  of  OMA,  an  Operations  Maintenance  Division  and  a  Naval  Aircraft 
Squadron,  as  well  as  on  descriptions  found  in  the  literature. 

Four  four  key  assumptions  of  this  thesis  are  that  the  Naval  Aviation  Logistics 
Command  Management  Information  System  for  OMAs  (NALCOMIS  OMA,  or 
NALCOM1S  Phase  III)  will  not  be  implemented  for  several  years  [Ref.  5:  pp. 

13-1 4],  that  there  is  no  interim  alternative  planned,  that  for  the  foreseeable  future 
Organizational  Maintenance  Activities  will  continue  to  be  without  sufficient  in¬ 
formation  systems  capability  to  make  the  best  possible  use  of  their  assets  in 
meeting  CNO  operational  readiness  and  safety  goals,  and  finally  that  an  interface 
between  the  proposed  system  (called  OASIS),  and  NALCOMIS  will  be  required. 

D.  RESEARCH  METHODOLOGY 

Research  into  the  current  status  of  Navy  systems,  both  fielded  and  under  i 

i 

»  i 

development,  was  conducted  both  in  the  literature  and  by  telephone  convcrsa- 
tions  with  NAVAIR  Program  Manager  Air  270  (PMA-270),  NAVAIR  code 
411 42  F  (Air-41 142F),  Naval  Sea  Logistics  Center  code  612.2 
(NAVSEALOGCEN-612.2),  Navy  Management  Systems  Support  Office  code 
51  (NAVMASSO-51),  and  Naval  Aviation  Maintenance  Office  code  02 
(NAMO-02).  Initial  intentions  to  continue  the  work  of  McCaffrey  [Ref.  6]  and 
Allen  &  McSwain  [Ref.  7]  in  the  area  of  Expert  and  Decision  Support  Systems 
were  overcome  by  the  need  for  an  overall  information  systems  plan.  Extensive 
telephone  conversations  between  the  author  and  NAMO  02  commencing  in  Au¬ 
gust  1989  confirmed  this  need.  * 


4 


E.  THESIS  ORGANIZATION 


The  remaining  chapters  of  this  thesis  are  as  follows: 

II.  Aviation  Maintenance  Organization.  A  general  description  of  how  the 
Naval  Aviation  Community  is  organized,  with  emphasis  on  the  OMA  and  its 
role. 

III.  Information  Systems.  Definitions  of  different  information  systems,  a 
brief  history  of  information  systems,  areas  of  current  emphasis  in  information 
systems,  and  a  description  of  information  systems  in  NAVAIR. 

IV.  Proposed  Information  System,  OASIS.  A  brief  discussion  of  strategic 
goals  and  functions,  a  review  of  NALCOMIS  functions  and  modules,  a  de¬ 
scription  of  the  proposed  OASIS  modules,  and  a  proposed  implementation 
plan. 

V.  Recommendations,  Further  Research,  and  Conclusions.  Recommen¬ 
dations  about  implementing  OASIS,  a  discussion  of  areas  needing  further  re¬ 
search,  and  conclusions. 


5 


II.  AVIATION  MAINTENANCE  ORGANIZATION 

A.  THREE  LEVELS  OF  MAINTENANCE 

Aircraft  maintenance  in  the  Navy  is  separated  into  three  levels,  Organiza¬ 
tional,  Intermediate,  and  Depot.  NAVAIR  described  the  three  levels  in  the  Naval 
Aviation  Maintenance  and  Material  Management  Manual  [Ref.  8],  Organizational 
maintenance  refers  "to  those  maintenance  functions  normally  performed  by  an 
operating  unit  in  support  of  its  own  operations."  [Ref.  8:  p.  1-4]  The  most  com¬ 
mon  Organizational  Maintenance  Activity  (OMA)  is  a  squadron  which  is  as¬ 
signed  a  specific  number  of  aircraft  and  people  with  which  to  perform  its 
mission(s).  Intermediate  maintenance  refers  "to  those  maintenance  functions 
normally  performed  in  centrally  located  facilities."  [Ref.  8:  p.  1-5]  Intermediate 
Maintenance  Activities  (IMAs)  typically  support  several  operating  units  repres¬ 
enting  several  different  types  of  aircraft  (e.g.,  E-2,  F-14,  A-6,  F  A- 18).  Depot 
maintenance  refers  to  maintenance  functions  performed  in  "industrial-type  es¬ 
tablishments,"  [Ref.  8:  p.  1-6]  known  today  as  Naval  Aviation  Depots  (NADEPs). 
The  most  common  of  these  functions  is  the  overhaul,  where  an  aircraft  is  taken 
apart,  inspected,  and  reassembled  with  new  or  reworked  parts. 

The  three  levels  of  maintenance  are  based  on  the  resources  available  at  the 
activity  (e.g.,  technical  ability,  facilities,  and  equipment).  Maintenance  functions 
arc  assigned  to  each  activity  by  matching  the  resources  required  to  perform  the 
particular  function  with  those  available  at  the  activity.  For  each  type  of  aircraft. 
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the  details  of  this  breakdown  of  maintenance  functions  is  developed  during  pro¬ 
curement  and  specified  in  the  Maintenance  Plan  for  that  aircraft. 

The  maintenance  plan  establishes  and  delineates  the  repairable  compo¬ 
nents  and  maintenance  requirements  of  a  selected  system  or  item  of  equip¬ 
ment.  For  each  repairable  component,  the  maintenance  plan  identifies  the 
maintenance  level  authorized  to  perform  the  maintenance  action  indicated, 
and  estimates  the  frequency  of  component  failure  or  repair  action.  [Ref.  9: 
P-5-4] 

There  is  no  special  relationship  among  OMAs,  IMAs,  and  NADEPS  other 
than  that  specified  by  their  respective  maintenance  levels  and  unique  capabilities. 
Any  IMA  is  allowed  to  provide  support  to  any  OMA  if  it  has  the  capability. 
Similarly,  any  NADEP  is  allowed  to  provide  support  to  any  IMA  or  OMA  if  it 
has  the  capability.  Note  that  not  all  O-leveP  capabilities  are  assigned  to  all 
OMAs;  nor  all  I-level  capabilities  to  all  IMAs;  nor  all  D-level  capabilities  to  all 
NADEPS.  Each  activity  has  its  own  assigned  capabilities.  For  example,  aerial 
refueling  stores  (ARS)  are  overhauled  at  NADEP  Alameda,  which  has  been  as¬ 
signed  responsibility  for  all  ARS. 

OMAs  are  the  operating  units.  They  are  the  most  mobile  and  consequently 
the  least  well  equipped  to  perform  major  repairs.  IMAs  are  located  in  major 
shore  stations  and  aboard  large  ships,  i.c.,  naval  air  stations  &  aircraft  carriers, 
and  have  more  in-depth  repair  capabilities  than  OMAs.  There  arc  six  NADEPs. 
all  located  in  the  continental  United  States  (CONUS).  They  all  have  the  basic 
capabilities  of  an  industrial  manufacturing  facility,  as  well  as  specific  responsi¬ 
bility  for  various  types  of  aircraft  and  equipment. 


I  "-level"  refers  to  the  maintenance  level  normally  associated  with  a  particular  maintenance 
capability— O-lcvcl  to  organizational  capabilities,  1 -level  to  intermediate,  and  D-level  to  depot,  l  or 
example,  replacing  the  wheel  assembly  on  an  aircraft  is  considered  an  O-level  capability,  but  re¬ 
placing  the  actual  tire  on  that  same  wheel  assembly  is  normally  an  1-level  capability. 
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B.  AVIATION  MAINTENANCE  PRINCIPLES 


The  Naval  Aviation  Maintenance  and  Material  Management  Manual  [Ref.  8] 
prescribed  "procedures  for  the  management  of  aircraft  maintenance  and  material 
at  organizational  and  intermediate  levels  of  maintenance."  [Ref.  8:  p.  I- 1  ]  Spe¬ 
cifically  described  are  two  broad  areas  of  aircraft  maintenance— a  Planned 
Maintenance  System  (PMS),  and  a  Maintenance  Data  Collection  System 
(MDCS)  [Ref.  8:  p.  I- 1  ].  The  stated  objective  of  these  systems  was  to  "insure  the 
highest  state  of  aircraft  readiness  and  reliability  at  the  lowest  cost  in  men,  money, 
and  material."  [Ref.  8:  p.  1-3]  The  Naval  Aviation  Maintenance  and  Material 
Management  Manual  [Ref.  8]  of  1967  has  become  OPNAVINST  4790. 2E  [Ref. 
1]  of  1989,  but  the  objective  is  still  "to  achieve  and  continually  improve  aviation 
material  readiness  and  safety  standards  established  by  the  Chief  of  Naval  Oper¬ 
ations  (CNO),  with  optimum  use  of  manpower,  material  and  funds."  [Ref.  9:  p. 
2-1] 

The  Planned  Maintenance  System  is  a  system  similar  to  that  provided  by 
automobile  manufacturers  to  their  customers.  The  PMS  is  derived  from  the 
maintenance  plan  for  that  aircraft,  and  specifies  that  certain  maintenance  actions 
be  performed  at  pre-determined  intervals  to  ensure  safe  and  efficient  operation 
of  the  aircraft  over  its  entire  planned  life2. 

Used  by  OMAs,  IMAs,  and  NADEPs,  the  Maintenance  Data  Collection 
System  is  a  system  for  collecting  data  about  every  maintenance  action  performed 

2  'Ilie  term  "scheduled  maintenance"  refers  to  those  actions  performed  at  the  prescribed  inter¬ 
vals.  "Unscheduled  maintenance"  refers  to  those  "unplanned"  maintenance  actions  performed  when 
something  breaks  or  doesn't  work  as  intended. 
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on  an  aircraft  or  component  of  an  aircraft.  It  also  provides  for  collecting  data 
about  parts  used,  man-hours  expended,  and  flight  operations  completed. 

The  Naval  Aviation  Maintenance  and  Material  Management  Manual  [Ref.  8) 
also  put  forth  two  principles  to  ensure  that  the  stated  objective  was  met.  Those 
principles  are  still  applied  today.  First  is  the  principle  of  "LOWEST  LEVEL 
MAINTENANCE".  This  principle  requires  "that  all  aircraft  maintenance  be 
performed  at  the  lowest  possible  level3."  [Ref.  8:  p.  1-6]  Application  of  this  prin¬ 
ciple  must  be  tempered  by  "optimum  economic  use  of  resources."  [Ref.  9  p.  2-1] 
For  example,  buying  a  million  dollar  set  of  test  equipment  for  every  OMA  if  each 
OMA  will  use  it  only  a  few  times  a  year  is  not  an  optimum  use  of  resources.  In¬ 
stead.  one  such  set  should  be  bought,  installed  at  an  IMA,  and  used  by  the  IMA 
to  perform  the  required  tests  for  several  OMAs. 

Second  is  the  principle  of  "MANAGEMENT  BY  EXCEPTION".  This 
means  "that  actions  or  incidents  which  vary  markedly  from  certain  standards  or 
norms  are  singled  out  or  'excepted'  from  the  whole  for  special  management  at¬ 
tention."  [Ref.  8:  p.  1-6]  The  Naval  Oil  Analysis  Program  (NOAP)  is  a  clear 
application  of  this  principle.  Oil  samples  are  taken  from  components  (mostly 
engines)  and  analyzed  for  traces  of  various  metals.  Depending  on  what  metal 
and  how  much  of  it  are  present  in  the  sample,  certain  actions  arc  dictated.  These 
actions  range  from  just  taking  another  sample  to  removing  and  replacing  the 
component.  This  same  principle  is  applied  in  a  more  macro  sense  to  OMAs. 
Higher  authorities  won't  interfere  with  the  way  an  OMA  is  performing  its  mission 
unless  the  statistics  reported  about  that  OMA  s  performance  and  readiness  bc- 

3  The  lowest  level  is  the  OMA,  with  the  IMA  and  NADLP  being  progressively  higher  levels. 
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come  an  exception  either  to  an  established  norm  or  to  that  OMA's  own  past  re¬ 
cord. 

In  short,  the  PMS  specifies  the  minimum  maintenance  that  must  be  done--the 
scheduled  maintenance;  the  exception  and  lowest  level  principles  cover  the  rest-- 
the  unscheduled  maintenance;  and  the  MDS  records  the  data  that  describe  all  the 
actions  pertaining  to  aircraft. 

C.  ORGANIZATIONAL  MAINTENANCE  ACTIVITY 

The  Maintenance  Department  of  an  OMA  is  made  up  of  several  work  cen¬ 
ters,  each  of  which  specializes  in  performing  a  particular  type  of  maintenance. 
For  example,  the  powerplants  work  center  will  generally  work  on  the  aircraft  en¬ 
gine  and  fuel  systems.  In  the  maintenance  department,  having  aircraft  ready  to 
fly  as  published  in  the  daily  flight  schedule  is  the  dominating  criterion  for  per¬ 
forming  maintenance  on  aircraft.  Coordinating  all  the  efforts  required  to  satisfy 
that  daily  flight  schedule  is  a  herculean  task  performed  by  the  most  experienced 
and  senior  enlisted  personnel  available,  usually  referred  to  as  Maintenance  Con¬ 
trol  Chiefs  (MCCs).  They  work  in  a  work  center  called,  not  surprisingly,  Main¬ 
tenance  Control  (MC).  Figure  1  on  page  1 1  is  a  diagram  of  the  functional 
relationships  within  an  OMA  Maintenance  Department.4 

In  addition  to  meeting  the  daily  flight  schedule,  MCCs  attempt  to  satisfy  all 
the  requirements  of  all  higher  authorities,  as  well  as  plan  for  all  known  future 


4  This  diagram  is  slightly  different  from  the  normal  "organization  chart"  for  an  OMA.  where 
MC  is  just  another  work  center  (Ref  10.  pp. 3-3,3-61.  This  reflects  the  fact  that  Maintenance  Con¬ 
trol  MUST  control  ALL  aspects  of  the  daily  maintenance  effort.  The  most  obvious  reason  for  this 
requirement  is  safety— having  electrically  activated  hydraulic  surfaces  unexpectedly  close  on  some¬ 
one  performing  maintenance  can  be  prevented  when  MC  is  in  control  because  MC  would  know 
not  to  allow  elect rical  power  on  that  aircraft. 
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Maintenance  Officer 


Figure  1.  OMA  Maintenance  Department  Functional  Relationships 

Adapted  from  [Ref.  10  :  p.  3-3] 

missions.  Higher  authority  requirements  are  specified  in  various  instructions  in¬ 
cluding  OPNAVINST  4790. 2E  [Ref.  I],  Fleet.  Type  and  Functional  Commander 
instructions,  squadron  instructions  and  maintenance  department  instructions. 

The  MCCs  typically  manage  the  minute  to  minute  maintenance,  making  de¬ 
cisions  about  which  aircraft  to  repair,  whom  to  assign  to  make  the  repair,  and 
when  to  actually  do  so.  Many  factors  enter  into  these  decisions,  including  worker 
experience  and  training,  availability  of  parts,  availability  of  tools,  sufficient  time 
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to  accomplish  the  repair,  other  demands  on  technicians,  and  the  criticality  of  the 
specific  repair  to  the  OMA's  immediate  and  long  range  missions. 

Long  range  strategic  maintenance  planning  is  managed  by  the 
Maintenance/ Material  Control  Officer,  and,  in  those  squadrons  fortunate  enough 
to  have  one,  a  senior  Master  Chief  Petty  Officer,  known  as  the  Maintenance 
Chief.  In  those  OMAs  without  a  Maintenance  Chief,  his  function  is  performed 
by  the  most  senior  and/or  experienced  MCC  available.  Strategic  planning  in¬ 
cludes  such  issues  as: 

•  determining  what  mix  of  airplanes,  people,  and  equipment  to  take  on  the 
next  detachment/deployment, 

•  coordinating  with  an  IMA  or  NADEP  for  aircraft  repairs  beyond  the  au¬ 
thorized  capability  of  the  OMA  itself, 

•  deciding  which  Technical  Directives  (TDs)  to  incorporate  in  which  aircraft, 
and  when  to  do  so, 

•  deciding  what  changes  to  make  to  the  maintenance  schedule  to  have  enough 
aircraft  available  to  take  on  the  next  detachment. 

The  quantity  of  information  required  to  plan  and  accomplish  both  the  minute 
to  minute  missions  and  the  long  range  ones  is  quite  large.  Knowledge  of  every 
maintenance  program,  all  governing  instructions,  each  piece  of  equipment,  and 
the  abilities  and  availability  of  both  people  and  equipment,  as  well  as  knowledge 
of  every  system  in  the  aircraft  are  some  of  the  key  elements  that  must  be  factored 
into  every  decision.  Add  the  one  constant  in  aviation  maintenance— change— and 
the  possibilities  are  staggering.  Aviation  maintenance  has  done  as  well  as  it  has 
for  so  long  ONLY  because  the  quality  of  the  people  in  these  critical  MCC  posi¬ 
tions  has  been  so  high. 
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How  much  better  could  OMAs  do  if  information  systems  were  at  their  dis¬ 
posal?  This  question  has  been  partially  answered  by  McCaffrey  [Ref.  6],  Allen 
[Ref.  1 1],  and  Allen  &  Mcswain  [Ref.  7]  in  their  theses.  These  authors  analyzed 
the  benefits  of  improved  OMA  information  systems  in  their  particular  area  of 
interest-expert  systems,  NALCOMIS,  and  decision  support  systems  respectively. 
The  systems  they  proposed  were  not  intended  to  be  a  complete  OMA  information 
system.  Their  proposals  represent  a  portion  of  OASIS,  and  should  be  integrated 
with  OASIS  to  form  one  overall  Information  System  specifically  aimed  at  OMA 
missions  and  goals. 

D.  INFORMATION  USERS  IN  AVIATION  MAINTENANCE 

Many  people  have  a  legitimate  need  for  information  about  naval  aviation, 
from  those  involved  in  direct  aircraft  maintenance  at  the  OMA  level,  through  the 
various  chains-of-command,  on  up  to  the  President  and  Congress.  The  demand 
for  information  has  grown  as  the  number,  complexity  and  required  administrative 
support  of  aircraft  has  grown.  An  example  of  the  growth  in  demand  for  infor¬ 
mation  is  Congressional  demand  for  reports  from  the  Department  of  Defense, 
which  grew  by  2000  percent  between  1970  and  1988  [Ref.  12].  Although  not 
specific  to  Naval  Aviation,  this  example  is  indicative  of  the  growth  in  demand  for 
information  in  general. 

Information  at  an  OMA  falls  in  two  categories-internal  and  external. 
Internal  information  is  information  intended  for  use  within  the  activity  to  achieve 
its  goals  and  perform  its  missions,  whereas  external  information  is  information 
generated  solely  to  satisfy  a  requirement  imposed  from  outside  the  activity  and 
has  no  value  within  the  activity  itself.  This  distinction  does  not  preclude  activities 
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from  using  information  originally  intended  for  others,  i.e.,  an  OMA  using  read¬ 
iness  information  required  by  its  operational  commander,  or  an  operational 
commander  requiring  information  primarily  intended  for  use  by  the  OMA.  In¬ 
stead,  the  distinction  will  help  in  assigning  priorities  to  the  information  require¬ 
ments  of  OMAs. 

An  additional  distinction  must  be  made  between  data  and  information.  Data 
are  "raw  facts  in  isolation. ...These  isolated  facts  convey  meaning  but  generally  are 

not  useful  by  themselves."  [Ref.  13:  p.  67]  Information  is 

...data  that  has  been  manipulated  so  it  is  useful  to  someone. ..Information 
must  tell  people  something  they  don't  already  know  or  confirm  something 
that  they  suspect.  It  should  be  noted  that  one  person's  information  may  be 
another  person's  data.  [Ref.  13:  p.  67] 

Implicit  in  these  definitions  is  the  fact  that  information  in  isolation  is  merely 
data  and  that  a  person  is  needed  to  attach  meaning  to  information.  Whether  it 
be  as  routine  as  "John  Doe  is  out  sick  today,"  or  as  sensitive  as  the  most  top  secret 
intelligence,  information  has  always  been  critical  to  managers  and  leaders.  To¬ 
day,  information  has  gained  widespread  recognition  as  a  strategic  resource  as 
important  as,  if  not  more  important  than,  physical  assets  [Refs.  14,  15  ,  and  16]. 

Within  the  OMA,  the  information  users  include  virtually  every  person  in  the 
OMA,  from  the  Commanding  Officer  (CO)  and  Executive  Officer  (XO),  through 
all  the  Department  Heads,  to  the  technicians  repairing  the  aircraft.  The  CO 

wants  to  know  what  is  happening  in  HIS  activity.  His  questions  include: 

•  How  many  aircraft  are  ready  to  fly?, 

•  How  much  money  do  we  have  left  for  fuel?, 

•  How  many  people  are  on  leave,  in  school,  or  going  on  the  next  detachment?. 

•  What  is  the  status  of  the  investigation  of  John  Doc's  accident?. 
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•  How  many  pilots  will  need  swim  re-qualification  during  the  next  detachment 
or  deployment? 

The  Department  Heads  want  to  know  the  same  things  as  the  CO  &  XO,  both 
to  take  care  of  problems  before  being  asked  for  explanations,  i.e.,  to  give  the  CO 
&  XO  solutions  rather  than  problems,  and  to  better  perform  their  own  jobs.  For 

example,  the  Maintenance  Officer  needs  to  know: 

•  Will  a  particular  aircraft  be  ready  to  fly  tomorrow?  next  week?  for  deploy¬ 
ment?, 

•  Are  the  parts  needed  for  the  next  detachment  pack-up  ready,  or  will  they 
be?, 

•  Have  the  necessary  schools  been  scheduled  for  technicians  making  the  next 
deployment?, 

•  Are  enough  tools  on  hand  to  perform  required  maintenance? 

In  Maintenance  Control  all  the  same  questions  must  be  answered  more  fre¬ 
quently,  as  well  as  some  more  detailed  ones.  Examples  are: 

•  What  inspections  are  due  today?  tomorrow?  next  week?, 

•  When  is  the  next  major  inspection  due?, 

•  Does  Power  Plants  have  enough  people  trained  to  change  three  engines  next 
week?, 

•  How  long  will  it  take  to  change  the  radio  in  aircraft  510?, 

•  Can  supply  get  us  a  new  radar  receiver  before  the  next  aircraft  launch,  or 
do  we  take  it  out  of  another  aircraft? 

•  Has  the  daily  inspection  been  completed  on  the  aircraft  next  to  launch? 

E.  SUMMARY 

In  summary,  the  naval  aviation  community  can  not  perform  its  mission 
without  the  right  information  available  to  the  right  people  when  they  need  it. 
From  the  top  planning  and  procurement  level.  NAVAIR,  through  the  operational 
levels,  to  the  lowest  level  of  maintenance,  the  OMA,  there  are  mans  users  of  in- 
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formation  systems.  Each  of  those  users  has  his  own  requirements  for  both 
quantity,  frequency  and  format  of  information.  Information  systems  (ISs),  the 
subject  of  the  next  chapter,  are  the  tools  used  to  satisfy  those  requirements. 
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III.  INFORMATION  SYSTEMS 


This  chapter  provides  a  general  discourse  of  information  systems  (IS)  and 
their  history,  a  discussion  of  current  emphasis  areas  on  information  systems  rele¬ 
vant  to  OASIS  (Organizational  Activity  Strategic  Information  System),  including 
applicable  development  techniques  and  methods,  and  a  review  of  information 
systems  in  aviation  maintenance. 

The  principle  function  of  information  systems  is  to  get  the  right  information 
to  the  right  people  at  the  right  time  in  a  form  that  they  will  use.  Stoner  and 
Wankel  say  that  "Only  with  accurate  and  timely  information  can  managers 
monitor  progress  toward  their  goals  and  turn  plans  into  reality."  [Ref.  17:  p.  619] 
Implicit  in  these  statements  is  that  an  information  system  MUST  be  focused  on 
the  goals  of  the  organization.  If  not,  the  IS  merely  drains  the  organization's  re¬ 
sources.  An  organization  can  not  long  survive,  or  in  the  case  of  an  OMA.  achieve 
high  readiness,  by  wasting  resources  such  as  capital  assets,  personnel  time,  man¬ 
agement  attention,  operating  costs,  and  productive  effort  on  an  IS  that  does 
nothing  to  achieve  organizational  goals. 

Information  has  four  basic  characteristics— quality,  timeliness,  quantity,  and 
relevance.  Information  must  accurately  reflect  the  situation  it  purports  to  de¬ 
scribe,  be  in  time  for  any  necessary  action  to  be  undertaken,  be  of  a  quantity  no 
more  and  no  less  than  the  manager  needs  or  can  process,  and  be  relevant  to  that 
manager's  organizational  function  [Ref.  17:  pp.  620-621].  Any  information  sys¬ 
tem.  to  be  of  value  to  an  organization,  should  emphasize  these  four  character- 
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istics.  This  emphasis  should  start  at  the  inception  of  an  IS,  continue  through  the 
design  and  implementation,  and  most  importantly,  be  among  the  determining 
criteria  for  any  "enhancements"  added  to  the  system  during  its  life. 

An  information  system  is  just  a  tool.  As  with  all  tools,  an  IS  can  be  misused, 
abused,  not  used,  or,  as  intended,  used  effectively  to  achieve  the  goals  of  the  or¬ 
ganization.  Failure  to  keep  the  organization's  goals  and  the  characteristics  of 
information  in  mind  during  IS  development  will  virtually  doom  an  information 
system  to  failure. 

Five  categories  of  information  systems  are  relevant  to  OASIS.  They  are 
transaction  processing  systems  (TPSs),  management  information  systems  (MISs), 
management  reporting  systems  (MRSs),  decision  support  systems  (DSSs).  and 
expert  systems  (ESs).  Each  of  these  will  be  discussed  in  the  following  sections. 
The  purpose  will  be  to  establish  some  working  definitions,  place  each  in  a  histor¬ 
ical  perspective,  add  the  current  IS  trends  of  relevance  to  OASIS,  and  finally  to 
describe  some  applicable  methods  and  techniques  for  development. 

A.  DEFINITIONS 

1.  Information  Systems 

There  are  many  definitions  of  information  systems.  In  simplest  terms,  an 
information  system  is  a  means  to  get  timely,  usable  information  to  the  managers 
or  the  knowledge  workers5  who  need  the  information.  More  formally: 

An  information  system  is  a  subsystem  of  the  business.  Specifically  it  is  a 
pcrson/machine  arrangement  of  components  that  interact  to  support  the  op- 

5  Knowledge  workers  arc  "...those  people  whose  jobs  involve  the  creation,  processing,  and 
distribution  of  information."  |Rcf.  13:  p.  40 1 
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erational,  managerial,  and  decision-making  information  needs  of  knowledge 
workers.  [Ref.  13:  p.  53] 

All  the  following  categories  of  information  systems  fit  within  this  broad  defi¬ 
nition.  The  framework  developed  by  Whitten,  Bentley  and  Ho,  Figure  2  on  page 
20,  is  useful  for  keeping  these  systems  in  perspective  relative  to  each  other.  This 
framework  is  also  useful  for  identifying  the  principle  knowledge- workers  that 
utilize  and  benefit  from  each  type  of  system. 

2.  Transaction  Processing  Systems 

A  transaction  processing  system  (TPS)  is  a  system  to  record,  store  and 
process  data  representing  events  important  to  an  organization.  The  "aim  of 
record-keeping  systems  is  the  processing  of  high  volumes  of  data,  not  providing 
support  for  decision  making."  [Ref.  18:  p.  446]  Transaction  processing  systems 
"include  payroll  preparation,  account  management,  and  savings  account  interest 
tabulations."  [Ref.  18:  p.  446]  A  transaction  processing  system  is  the  foundation 
of  an  information  system.  Without  the  data  a  TPS  collects  and  stores,  there  can 
be  no  information. 

3.  Management  Information  Systems 

A  Management  Information  System  is  a  system  that  provides  manage¬ 
ment  the  information  (not  just  data)  they  need,  in  the  form  they  need  it.  in  time 
for  them  to  use  that  information  to  the  benefit  of  the  organization.  MISs  are 
typically  used  to  aid  managers  in  making  those  decisions  that  occur  regularly,  and 
for  which  there  are  pre-defined  procedures  or  rules.  An  MIS  is  "an  integrated 
system  for  providing  information  to  support  the  planning,  control  and  operations 
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Source:  Whitten,  Bentley  and  Ho  [Ref.  13  :  p.  79] 


of  an  organization."  [Ref.  18:  p.  498]  A  more  rigorous  and  formal  definition  is 
that  an  MIS  is: 

a  formal  method  of  making  available  to  management  the  accurate  and  timely 
information  necessary  to  facilitate  the  decision-making  process  and  enable  the 
organization' s  planning,  control,  and  operational  functions  to  be  carried  out 
effectively.  [Ref.  17:  p.  622] 

4.  Management  Reporting  Systems 

Management  reporting  systems  are  systems  which  produce,  at  specified 
intervals,  pre-dcfined  reports  based  on  the  data  collected  and  stored  by  its  sup¬ 
porting  TPS.  There  are  three  types  or  reports.  The  first  is  the  detail  report.  This 
is  simply  a  detailed  listing  of  transactions  recorded  by  the  TPS.  These  are  useful 
for  transaction  verification.  The  second  report  is  the  summary  report.  This  is. 
as  the  name  implies,  a  summary  of  the  details  of  transactions.  Summary  reports 
are  typically  used  to  identify  key  items  of  interest  to  management,  e.g..  sales,  in¬ 
terest  paid  or  earned,  profit  loss,  or  outstanding  orders.  The  third  type  of  report 
is  the  exception  report.  This  is  a  report  to  which  some  preset  conditions  have 
been  applied  as  a  filter,  presenting  the  manager  with  only  the  exceptions  to  his 
predefined  rules  (filters).  An  example  of  such  a  report  is  a  list  of  inventory  items 
that  are  low  and  need  to  be  ordered.  [Ref.  13:  pp.  71-73]  A  manager,  by  pre¬ 
defining  the  filter  settings  minimizes  the  time  that  must  be  spent  manually  filter¬ 
ing  the  data  in  order  to  obtain  needed  relevant  information. 

5.  Decision  Support  Systems 

Even  though  the  term  "decision  support  system"  has  been  in  use  since  the 
early  1970s.  "there  is  still  no  strict  definition  of  its  meaning.  For  many  writers. 
DSS  is  a  philosophy,  a  way  to  seek  a  useful  complementarity  between  technolog- 
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ical  tools  and  human  judgment  and  discretion."  [Ref.  19:  p.  v]  Sprague  and 
Carlson,  in  what  is  considered  the  classic  DSS  treatise,  say  that  "DSS  comprise 
a  class  of  information  system  that  draws  on  transaction  processing  systems  and 
interacts  with  other  parts  of  the  overall  information  system  to  support  the 
decision-makinfo  activities  of  managers  and  other  knowledge  workers  in  organ¬ 
izations."  [Ref.  20:  p.  9]  Bennett  says  that  "A  DSS  is  a  coherent  system  of 
computer-based  technology  (hardware,  software,  and  supporting  documentation) 
used  by  managers  as  an  aid  to  their  decision  making  in  semistructurcd  decision 
tasks."  [Ref.  21:  p.  1]  Turban  provides  what  he  calls  a  "Working  Definition"  of 
DSS: 

A  DSS  is  an  interactive  flexible  and  adaptable  CBIS  [Computer-based  in¬ 
formation  system]  that  utilizes  decision  rules,  models  and  model  base  coupled 
with  a  comprehensive  database  and  the  decision  maker's  own  insights,  lead¬ 
ing  to  specific,  implementable  decisions  in  solving  problems  that  would  not 
be  amenable  to  management  science  optimization  modeh*  per  se.  Thus,  a 
DSS  support  complex  decision  making  and  increase  their  effectiveness.  [Ref. 
22:  p.  73] 

All  of  these  definitions  hav  e  two  common  threads.  First  is  supporting  the 
decision-maker  in  decision  situations  for  which  pre-defined  procedures  or  rules 
do  not  exist  or  arc  incomplete,  and  second  is  improving  the  effectiveness  of  the 
decision-maker's  decisions.  A  DSS  is  composed  of  three  major  subsystems,  the 
Data  Management  Subsystem,  the  Model  Management  Subsystem,  and  the  Di¬ 
alog  Management  Subsystem  [Ref.  20:  pp.  28-35],  These  are  shown  conceptually 
in  Figure  3  on  page  23.  As  DSSs  are  one  of  the  more  recent  developments  they 
are  discussed  in  more  detail  in  “2.  Decision  Support  Systems"  on  page  33. 


Manager  (User) 
and  Tasks 


Figure  3.  Conceptual  model  of  Decision  Support  System 

Source:  Turban  figure  3.2  [Ref.  22  :  p.  75] 

6.  Expert  Systems 

Expert  systems  (ES)  are  the  latest  type  of  information  system  to  be  em¬ 
braced  by  business  organizations.  An  expert  system  is  a  computer  based  system 
used  to  consistently  leverage  the  knowledge  of  an  expert  (or  experts)  to  the  ad¬ 
vantage  of  an  organization,  independent  of  access  to  the  expert(s).  Because  it  is 
the  latest  bandwagon,  many  authors  have  jumped  aboard,  and  definitions  of  ES 
abound.  Turban  says  that: 
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Expert  systems  are  computerized  advisory  programs  that  attempt  to  imitate 
or  substitute  the  reasoning  processes  and  knowledge  of  experts  in  solving 
specific  types  of  problems.  [Ref.  22  :  p.  321] 

Whitten,  Bentley  and  Ho  say  that: 

In  an  expert  system,  the  expertise  and  knowledge  associated  with  decision 
making  is  stored  in  a  knowledge  base.  Programs  are  written  to  access  the 
knowledge  bases  and  databases  to  identify  and  make  decisions....  [Ref.  13:  p. 

454] 

Walters  and  Nielsen  even  eschew  the  term  "expert  system"  in  favor  of 
"Knowledge-based  systems"  about  which  they  say: 

In  the  simplest  of  terms,  the  notion  behind  knowledge-based  systems  is  to 
capture  the  problem-solving  expertise  of  a  human  being— an  expert  in  a  highly 
constrained  problem  area,  called  a  problem  domain— and  represent  this  per¬ 
son  s  knowledge  or  expertise  in  a  computer  in  such  a  way  that  the  computer 
can  approximate  the  expert's  abilitv  to  solve  a  particular  class  of  problems. 
[Ref.  23:  p.  4] 

An  expert  system  is  composed  of  three  basic  components.  First  is  the 
knowledge  base,  made  up  of  rules,  heuristics  and  facts  about  the  subject  area. 
Second  is  the  inference  engine  which  contains  the  program  with  which  the  ES 
"reasons"  and  reaches  a  conclusion.  Third  are  the  interfaces  that  connect  the  in¬ 
ference  engine  to  the  user,  knowledge  engineer,  and  the  explanation  subsystem. 
The  knowledge  engineer  is  the  person  who  gathers  the  expert's  knowledge  and 
converts  it  to  the  form  needed  by  the  knowledge  base.  Figure  4  on  page  26  shows 
the  typical  organization  of  a  knowledge  based  system.  The  components  in  the 
Development  Environment  are  the  tools  used  by  the  knowledge  engineer  or  sys¬ 
tem  developers.  The  Delivery  Environment  is  what  will  actually  be  the 
knowledge-based  system  delivered  to  the  user.  As  with  DSSs.  additional  dis- 
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cussion  of  the  aspects  of  ESs  relevant  to  OASIS  can  be  found  in  “3.  Expert 
Systems”  on  page  35. 

B.  BRIEF  HISTORY  OF  INFORMATION  SYSTEMS 
1.  The  Business  Focus 

Information  Systems  (ISs)  have  always  existed  in  one  form  or  another. 
They  have  been  used  to  gather,  retain,  and  use  information  about  something  of 
interest  to  the  user.  In  early  society,  people  retained  information  about  basic 
necessities  such  as  where  to  hunt,  which  animals  to  pursue,  and  which  plants 
were  safe  to  eat.  People  still,  in  their  personal  lives,  practice  storing  and  proc¬ 
essing  information  of  interest  to  them.  Libraries  are  another  example  of  infor¬ 
mation  gathering  and  storing.  Today  however,  with  many  such  basic 
"information  systems"  taken  for  granted,  the  term  "information  system"  has  come 
to  mean  a  business-oriented  computer  based  system. 

The  invention  of  the  electronic  computer  in  the  1950s  brought  a  revo¬ 
lution  to  information  systems.  In  what  is  called  the  "Computer  Age,"  [Ref.  25: 
pp.  2-3]  the  computer  changed  the  way  data  was  collected  and  used.  Rooted  in 
the  manual  accounting  systems  of  business,  computer-based  accounting  systems 
took  over  gathering  the  data  needed  by  owners  and  managers  to  measure  the 
performance  of  their  businesses.  Business  owners  and  managers  asked  such 
questions  as: 

•  Were  they  making  a  profit?. 

•  Was  the  profit  as  much  as  the  previous  day?  week?  month?  year?. 

•  Were  their  costs  going  up  or  down?, 

•  Was  there  a  trend  in  sales,  up  or  down? 
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Figure  4.  Anatomy  of  a  Knowledge-based  System 

Source:  Carrico,  et  al.  Figure  1-2  [Ref.  24  :  p.  5] 

Computerized  information  systems,  specifically  accounting  systems,  provided  an¬ 
swers.  or  the  data  from  which  answers  could  be  derived. 

One  of  the  key  characteristics  of  these  early  information  systems  was: 


...their  facility  in  dealing  with  well-structured  and  routine  processes  that 
computers  can  easily  handle.  The  procedures  may  be  repeated  many  times 
during  the  course  of  a  day,  week,  or  month.  They  arc  also  well  understood, 
to  the  extent  that  clearly  specified  procedures  can  be  formulated.  [Ref.  IS: 
p.  446] 
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Since  computers,  with  correct  instructions,  perform  faster,  more  accurately,  and 
more  consistently  than  people,  they  were  (and  still  are)  used  to  perform  the  rou¬ 
tine  functions  of  storing,  sorting,  and  summarizing  the  data  collected  in  these  ac¬ 
counting  systems. 

One  of  the  reasons  computers  were  accepted  as  information  handling 
tools  was  the  tremendous  increase  in  the  quantity  of  data  being  gathered,  stored, 
and  used.  Manual  information  systems  were  unable  to  keep  up.  Entire  computer 
systems  had  to  be  dedicated  to  the  task  of  collecting  data,  manipulating  that  data 
in  some  fashion,  and  generating  periodic  reports  based  on  the  data.  The  systems 
built  to  perform  these  functions  were,  and  still  are  called  transaction  processing 
systems  (TPSs). 

Transaction  processing  systems  started  as  manual  systems,  and  many 
manual  systems  are  still  in  use.6  The  first  computer  based  TPSs  were  frequently 
built  simply  to  automate  an  existing  manual  system.  Some  people  still  think  of 
TPSs  as  mere  automatic  manual  systems.  Senn.  for  example,  says  that  "Trans¬ 
action  processing  systems  substitute  computer  processing  for  manual  record¬ 
keeping  procedures."  [Ref.  18:  p.  446] 

In  the  1960s  and  1970s.  as  managers  were  inundated  with  rooms  full  of 
printed  reports,  they  realized  they  were  wasting  their  time  trying  to  extract  what 
they  needed  from  those  reports.  What  they  really  needed  was  information,  not 
piles  of  data.  Management  information  systems  (MISs)  were  heralded  as  the 
solution  to  the  data  glut.  MISs  were  made  possible  by  a  rapid  improvement  in 

6  Some  organizations  have  chosen,  for  cost,  fear,  simplicity,  or  some  other  reason,  not  to  use 
computers 
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computer  technology  and  a  growing  knowledge  of  how  to  effectively  apply  that 
technology.  In  fact,  advances  in  technology  and  knowledge  made  development 
of  newer  and  better  information  systems  inevitable.  By  their  very  name,  man¬ 
agement  information  systems  offered  management  the  promise  of  real  informa¬ 
tion.  Recall  that  information  is  "data  that  has  been  manipulated  so  it  is  useful 
to  someone."  [Ref.  13:  p.  67]  Developed  principally  to  satisfy  the  need  to  reduce 
the  large  quantity  of  data  to  usable  information,  management  information  sys¬ 
tems  also  allowed  management  to  gain  better  control  of  the  resources  being  ex¬ 
pended  on  TPSs,  e.g.,  capital  and  personnel. 

Management  Information  Systems  never  fulfilled  their  promise.  The 
"idea  of  building  a  single,  integrated  management  information  system  (MIS)  for 
any  and  all  organizations. ..never  really  got  off  the  ground."  [Ref.  13:  p.  1 16]  In¬ 
stead,  MISs  frequently  became  just  management  reporting  systems  (MRSs),  in 
reality,  little  more  than  a  TPS  with  better  report  generating  capability.  One  of 
the  reasons  MISs  failed  to  become  all  they  were  intended  was  the  inability  of 
management  to  define  their  requirements,  and  then  to  stabilize  those  require¬ 
ments  long  enough  for  the  MIS  to  be  completed.  Management's  "information 
needs  were  so  numerous,  volatile,  and  diverse  that  it  would  take  an  enormous 
staff  of  analysts  and  programmers  to  fulfill."  [Ref.  13:  p.  116]  This  problem  is 
not  likely  to  change.  Management's  requirements  are,  of  necessity,  always 
changing  to  keep  pace  with  their  ever  changing  environment,  and  information 
systems  must  likewise  change. 

Another  problem  with  MISs,  and  in  fact  with  many  information  systems 
of  the  1960s  and  1970s,  was  inflexibility.  The  internal  workings  of  computers  arc 
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quite  rigid.  A  computer's  representation  of  "w"  is  not  the  same  as  that  for  "W". 
This  type  of  distinction  is  basic  to  a  computer's  operation,  and  therefore  implies 
that  once  a  system  was  implemented  and  being  used,  it  could  be  adapted  to  new 
requirements  only  by  a  huge  expenditure  of  additional  resources.  Consequently, 
attempting  to  "apply  a  very  rigid,  unforgiving  technology  to  a  very  flexible  and 
often  unpredictable  business  situation"  [Ref.  13:  p.  115]  met  with  limited  success. 
This  failure  is  attributed  to  trying  to  satisfy  the  needs  of  an  "open  system"  with 
a  "closed  system."  "An  open  s\‘stem  doesn't  have  well-defined  interactions  with 
its  environment,"  whereas  "A  closed  system  has  a  precise  number  of  well-defined 
inputs  and  outputs."  [Ref.  13:  p.  115]  Since  the  application  of  a  closed  system 
solution  to  an  open  system  problem  didn't  work  well,  another  approach  to  using 
the  technology  was  necessary. 

Further  developments  in  available  technology,  both  hardware  and  soft¬ 
ware.  continued  to  occur,  and  decision  support  systems  (DSSs)  came  into  being. 
Whereas  MISs  were  aimed  at  the  routine,  well-structured  decisions  of  middle 
managers,  "DSS  arc  focused  still  higher  in  the  organization."  and  more  toward 
Jess  well  structured  decision  problems.  [Ref.  20:  p.  7]  DSS  arc  "  Dedicated  to 
improving  the  performance  of  knowledge  workers  in  organizations  through  the 
application  of  information  technology."  [Ref.  20  :  p.  8]  DSSs  provide  the  user, 
manager,  or  knowledge-worker,  with  greater  flexibility  in  data  manipulation,  and 
also  extract  data  from  various  sources  and  generate  reports  on  that  data.  In  fact. 
DSS  have  added  an  "on  demand"  and  "custom"  report  ability  to  the  manipulating 
and  reporting  functions  of  TPSs  &  MISs. 
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2.  Artificial  Intelligence  and  Expert  Systems 

While  the  business  oriented  TPS,  MIS,  and  DSS  were  evolving,  a  parailel 
evolution  was  occurring.  At  a  conference  in  1956  at  Dartmouth  College,  Artifi¬ 
cial  Intelligence  (AI)  was  "born."  Artificial  intelligence  is  "an  umbrella  term  for 
a  variety  of  fields  of  study  that  include  robotics,  cognitive  science,  vision  systems, 
natural  language  understanding,  sound  recognition,  and  knowledge  systems." 
[Ref.  24:  p.  15]  In  spite  of  the  similarity  to  humans,  predictions  that  computers 
would  be  able  to  think  and  learn,  and  ultimately  replace  humans,  proved  pre¬ 
mature.  In  fact,  only  in  the  past  decade  has  AI  enjoyed  any  significant  com¬ 
mercial  success,  and  that  has  been  primarily  in  the  branch  of  AI  called  Expert 
Systems.  A  key  distinction  between  the  business  oriented  systems  (TPS.  MIS. 
MRS  &  DSS)  and  ES  is  the  means  by  which  each  solves  problems.  The  business 
oriented  systems  apply  a  pre-defined  step-by-step  procedure,  called  a  "program," 
to  a  set  of  data  and  arrive  at  some  resur.  With  ES,  the  procedure  is  not  pre¬ 
defined.  Rules,  facts,  and  heuristics7  are  stored  and  invoked  as  necessary  or 
applicable-not  in  any  pre-defined  specific  order.  The  latter  is  actually  the  wav- 
humans  think.  We  have  stored  a  wealth  of  learned  facts,  experience-based 
heuristics,  and  known  rules  that  we  apply  both  to  routine  situations,  such  as 
driving  a  car,  and  to  new  situations,  such  as  learning  to  drive  a  boat  or  an  air¬ 
plane.  Some  recent  examples  of  successful  ES  applications  include: 

•  an  ES  to  generate  "an  hour-by-hour  baking  schedule",  screen  job  applicants, 
and  write  labor  schedules  for  Mrs.  Fields,  Inc.  [Ref.  26:  p.  1], 

7  "Heuristics.. .are  decision  rules  regarding  how  a  problem  should  be  solved  [Ref.  22:  p  5f l| 
They  amount  to  "educated  guesses"  about  the  solution  to  a  problem. 
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•  Digital  Equipment  Corporation  uses  an  ES  (XCON)  to  customize  the  con¬ 
figuration  of  VAX  and  PDP-11  computers  prior  to  manufacture.  [Ref.  27, 
and  28], 

•  an  ES  is  being  used  to  help  solve  the  African  food  shortage  through 
aquaculture-fish  farming  [Ref.  29:  p.  57], 

•  using  an  ES  to  optimize  the  use  of  limited  satellite  launching  resources  [Ref. 
29:  p.  58],  and 

•  using  an  ES  to  plan  the  refueling  of  NASA's  space  shuttle  [Ref.  30], 

To  date,  most  military  applications  in  the  literature  are  only  prototypes, 
and  a  majority  of  those  are  in  the  avionics  troubleshooting,  fault  isolation  area 
where  a  substantial  rule  base  can  be  defined.  However,  just  putting  the  mainte¬ 
nance  troubleshooting  procedures  (decision  trees),  written  in  the  form  of  "if-then" 
rules,  into  the  ES  knowledge  base  is  not  all  that  is  required.  That  is  because  "too 
many  unexpected  causes  of  equipment  malfunctions  cannot  be  anticipated  in  a 
traditional  if-then  rule-based. ..paradigm."  [Ref.  31:  p.  1335]  Examples  of  such 
malfunctions  include  spilled  solder,  damage  from  other  equipment,  or  spilled 
coffee  [Ref.  31:  p.  1 335].  Some  examples  of  the  prototypes  developed  and  pub¬ 
lished  include: 

•  an  ES  to  isolate  faults  in  "the  fuel  system,  the  flight  control  system,  the 
auxiliary  power  unit,  and  the  av  ionics  systems."  of  the  Army's  AH-6-4A  At¬ 
tack  Helicopters  [Ref.  32:.  p.  43], 

•  a  prototype  ES  to  make  maintenance  personnel  assignments  for  a  helicopter 
squadron's  many  detachments  [Ref.  33].  and 

•  using  an  ES  to  find  the  cause  of  electrical  or  hydraulic  system  failures  in  the 
Navy's  H-46  helicopter  [Ref.  34]. 

C.  CURRENT  EMPHASIS  IN  INFORMATION  SYSTEMS 
I.  Information  as  a  Resource 

Most  recent  texts  and  writings  about  information  systems  begin  by 
stressing  the  importance  of  information  as  a  corporate  resource.  For  example: 


In  many  organizations,  the  focus  of  information  systems  management  has 
changed.  In  the  past,  the  emphasis  was  primarily  on  managing  computers 
and  the  technology  to  process  information. ..the  primary  concern  has  shifted 
to  the  information  in  computer  systems  itself,  and  the  need  to  manage  it  as  a 
resource.  ...information  itself  has  become  a  strategic  resource,  requiring  its 
own  policies  and  procedures  for  management  and  control.  [Ref.  16:  p.  643] 

...computerized  information  is  a  resource  of  high  value  to  corporations  and 
other  organizations.  [Ref.  15:  p.  xix] 

Such  thinking  has  changed  the  context  in  which  organizations  view  information 
systems.  Transaction  processing  systems  for  example  are  no  longer  an  end  in 
themselves.  Instead,  a  TPS  must  be  an  integral  part  of  an  overall  IS  targeted  at 
achieving  one  or  more  of  the  goals  of  the  organization.  Simply  automating  an 
existing  system  is  not  enough.  Instead,  every  bit  of  data  must  in  some  way  con¬ 
tribute  to  the  success  of  the  organization.  This  requires  a  reevaluation  of  the  data 
being  recorded.  Claiming  "we've  always  collected  it"  is  no  longer  justification  for 
including  data  in  a  system.  In  some  cases  a  complete  change  in  the  transaction 
processing  system,  computer-based  or  manual,  may  be  required.  A  TPS  may  be 
the  foundation  of  any  information  system,  but  now  an  entire  mission-oriented 
information  system  is  built  on  that  foundation.  That  system  is  based  on  the 
premises  that  information  is  one  of  the  organization's  limited  resources  and  that 
all  the  organization's  resources,  including  information,  must  be  used  to  achieve 
organizational  goals. 

Information  systems  no  longer  merely  record  data  and  fill  rooms  with 
printed  reports  that  arc  seldom  used.  Not  only  must  they  provide  periodic 
printed  reports,  but  now  the  reports  must  be  provided  on  an  ad  hoc  basis  in  an 
easy  to  use  format.  That  format  has  even  taken  on  many  forms  beyond  the 
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simple  columnar  report.  Today,  information  can  be  presented  in  a  variety  of 
media  from  print  to  video  and  sound.  Graphic  displays  are  commonplace,  with 
even  the  most  basic  off-the-shelf  spreadsheet  package  having  some  graphing  ca¬ 
pability.  Formats  for  presenting  information  to  the  user  are  limited  only  by 
available  technology  and  by  the  user's  willingness  to  pay.  Additionally,  in  those 
organizations  that  have  matured  in  their  use  of  information  technology,  infor¬ 
mation  systems  are  even  being  used  to  gain  and  keep  a  strategic  advantage  in 
their  business  environment.  A  well  known  example  is  that  of  American  Hospital 
Corporation.  They  use  information  technology  to  provide  better  service  to  their 
customers  and  thereby  increase  their  share  of  the  medical  supplies  market.  [Ref. 
3:  pp.  217-234] 

2.  Decision  Support  Systems 

Decision  support  systems  (DSSs)  started  in  the  early  1970s.  and  are  used 
extensively  today.  Some  say  that  any  system  that  helps  a  decision-maker  make 
a  decision  is  a  DSS.  Keen  and  Scott-Morton  refined  the  scope  of  DSS  in  1978 
[Ref.  35].  Since  then,  much  work  has  been  accomplished,  and  DSS  have  taken 
on  the  definition  stated  earlier.  As  the  reader  will  recall  from  Figure  3  on  page 
23.  there  are  three  subsystems  in  a  DSS.  The  first,  the  Data  Management  Sub¬ 
system,  typically  has  several  elements,  including  a  database,  a  database  manage¬ 
ment  system,  a  data  directory,  and  some  sort  of  query  facility.  This  subsystem 
is  intended  to  manage  the  data  needs  of  the  DSS  and  user.  [Ref.  22:  pp.  76-82] 
The  Model  Management  Subsystem  has  comparable  elements,  a  model  base,  a 
model  base  management  system,  a  model  directory,  and  a  model  execution,  inte¬ 
gration  and  command  facility.  [Ref.  22:  pp.  82-83]  The  Model  Management 
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Subsystem  is  intended  to  manage  the  assortment  of  models  that  a  user  may  need 
to  invoke  while  using  the  DSS.  The  Dialog  Management  Subsystem  is  "the  soft¬ 
ware  and  hardware  that  provides  the  user  interface  for  DSS."  [Ref.  22:  p.  86] 
The  three  key  elements  for  the  dialog  component  of  a  DSS  are  the  language  with 
which  the  user  interacts  with  the  DSS,  the  type  of  presentation  the  DSS  provides 
the  user,  and  the  knowledge  the  user  must  possess  to  use  the  DSS  effectively  [Ref. 
36].  Perhaps  describing  characteristics  of  DSSs  will  make  the  differences  between 
DSSs  and  earlier  information  systems,  i.e.,  TPSs  &  MISs,  clearer.  According  to 

Turban  DSSs  have  four  characteristics.  They  are: 

•  "DSS  incorporate  both  data  and  models." 

•  "They  are  designed  to  assist  managers  in  their  decision  processes  in  semi- 
structured  (or  unstructured)  tasks." 

•  "They  support,  rather  than  replace,  managerial  judgment." 

•  "The  objective  of  DSS  is  to  improve  the  effectiveness  of  the  decisions,  not 
the  efficiency  with  which  decisions  are  being  made."  [Ref.  22:  p.  8] 

Sprague  and  Carlson  [Ref.  20]  provide  a  framework  for  developing  a  DSS 
that  they  call  ROMC.  Representations  are  those  things  decision-makers  use  to 
visualize  a  particular  problem;  Operations  arc  those  actions  taken  with  those 
representations  (which  include  gathering  and  manipulating  data);  Memory  Aids 
are  those  mechanisms  used  to  help  the  decision-maker  retain  intermediate  data 
from  operations  with  representations;  and  Control  Mechanisms  are  the  mechanics 
used  to  control  the  representations,  operations,  memory  aids,  and  interactions 
with  each  user.  "The  ROMC  approach  provides  a  process-independent  (italics 
mine)  model  for  organizing  and  conducting  systems  analysis  in  DSS."  [Ref.  20: 
p.  102]  The  critical  point  is  that  the  analysis  and  design  of  a  DSS  should  be  in- 
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dependent  of  all  processes  performed  in  the  system  being  analyzed.  Process 
modeling  is  the  way  traditional  transaction  processing  systems  (TPSs)  have  been 
analyzed.  The  tools  of  traditional  systems  development,  such  as  flowcharts, 
dataflow  diagrams,  and  entity-relationship  diagrams  are  all  process-oriented,  and 
not  appropriate  for  analysis  of  a  DSS.  [Ref.  20:  pp.  94-102] 

3.  Expert  Systems 

Expert  systems  evolved  from  principles  and  techniques  developed  in  the 
academic  world  of  artificial  intelligence.  "Artificial  Intelligence.  To  these  words 
each  of  us  brings  his  own  definition."  [Ref.  37]  To  some,  AI  conjures  up  the 
horror  of  computers  run  amok  (remember  HAL).  To  others,  AI  is  something  for 
academicians  and  computer  "geeks,"  but  is  not  real.  The  best  perspective  comes 
form  Shipley  when  he  says 

Because  Artificial  Intelligence  is  an  ambition  more  than  a  product,  the  tech¬ 
nologies  and  methodologies  that  grow  out  of  this  field  are  not  AI.  Instead, 
artificial  intelligence  research  is  leaving  a  trail  of  tools  and  techniques  that  arc 
enhancing  the  state  of  the  art  in  computer  applications  development  but  arc 
in  no  real  way  intelligent  themselves.  Or,  as  the  well-known  adage  in  the  A I 
research  community  goes,  artificial  intelligence  refers  to  those  things  we  don't 
know  how  to  do  today.  As  soon  as  we  figure  out  how  to  do  them,  they  won't 
be  AI. 

The  point  may  seem  simple,  but  it  is  absolutely  essential  to  under¬ 
standing  the  misunderstanding,  disillusionment,  and  initial  failure  of  com¬ 
mercial  AI.  [Ref.  37] 

Expert  systems  are  in  reality  simply  computer  programs  that  manifest 
"some  combination  of  concepts,  procedures,  and  techniques  derived  from  recent 
AI  research."  [Ref.  38:  p.  5]  They  are  the  latest  tool  to  become  commercially 
available  to  information  systems  developers,  and  thereby,  the  end-users.  How¬ 
ever,  the  increasingly  sophisticated  IS  users  are  unlikely  to  apply  ES  technology 


35 


just  because  it  is  new.  "...people  buy  products  to  solve  problems. ..they  don't  buy 
technologies...."  [Ref.  37]  End-users  will  evaluate  ES  on  the  basis  of  whether  that 
ES  can  solve  problems. 

The  principle  benefit  that  aviation  maintenance  can  derive  from  expert 
systems  is  consistently  leveraged  expertise.  Consistent  because  an  ES  docs  not 
become  fatigued,  is  not  subject  to  high  stress,  and  can't  be  distracted.  Therefore, 
the  mistakes  that  even  experts  could  make  when  tired,  stressed,  or  distracted 
would  not  be  made  by  an  ES,  or  by  someone  consulting  an  ES.  This  is  not  to  say 
an  ES  is  infallible.  In  fact,  an  ES  is  only  as  good  as  the  expertise  in  its  knowledge 
base,  and  that  expertise  is  a  function  of  the  expertise  of  the  original  expert  and 
the  accuracy  with  which  the  knowledge  engineer  translated  that  expert's  know¬ 
ledge  into  an  ES.  Nor  can  an  ES  "know"  everything,  any  more  than  a  human 
expert.  However,  unlike  the  human  expert,  an  ES  has  no  ego  to  get  in  the  way 
of  saying  "I  don't  know."  Instead,  depending  on  how  the  inference  engine  is 
"trained"  to  respond,  an  ES  will  either  ask  the  user  for  more  data,  or  provide  the 
user  a  conditional  response. 

The  leverage  derives  from  the  fact  that  once  in  the  ES,  the  expert's  ex¬ 
pertise  can  be  used  by  anyone,  anywhere.  The  expert  docs  not  even  need  to  be 
by  the  phone!  Additionally,  experts,  rather  than  spending  their  time  solving 
routine  problems,  are  free  to  spend  their  time  on  those  decisions  for  which  the 
expertise  has  not  yet  been  captured,  or  for  which  a  computer-based  system  is  in¬ 
appropriate. 

"Expert  systems  free  workers  from  more  mundane  tasks  so  that  they  can 
spend  their  time  on  more  difficult  problems  or  more  creative  endeavors.  De- 
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cisions  are  made  consistently  from  worker  to  worker,  and  the  know-how  of 
top  employees  and  specialists  can  be  distributed  throughout  the  corporation. 

Expert  systems  also  translate  directly  into  cost  savings.  An  IBM  di¬ 
agnostic  system  saved  S12  million  per  year. ..by  avoiding  misdiagnoses  and  the 
accidental  disposal  of  good  parts.  DuPont,  a  true  believer  in  expert  systems 
spends  an  average  S25,000  to  build  a  system  that  promises  an  initial  payback 
of  SI 00,000."  [Ref.  37] 

So,  by  providing  the  expert's  knowledge  to  a  large  number  of  organizations,  in  the 
form  of  an  ES,  we,  aviation  maintenance  managers,  in  essence  multiply  the 
number  of  experts  we  have,  AND  use  them  more  effectively. 

Through  the  1960s  and  1970s,  computers  evolved  in  two  directions.  In 
the  scientific  and  academic  communities,  the  focus  was  on  number  crunching  and 
artificial  intelligence.  In  the  business  community,  the  focus  was  on  automated 
accounting,  financial  reporting,  and  rudimentary  information  management.  To¬ 
day,  as  the  integration  of  TPS,  MIS,  DSS  and  ES  occurs  in  the  "Information 
Age,"  we  are  beginning  to  re-unite  those  once  separate  paths  of  information  sys¬ 
tems  development  [Ref.  25:  pp.  2-3]. 

4.  End-User  Development 

"One  of  the  most  exciting  trends  on  the  people  front  of  information  sys¬ 
tems  involves  knowledge  workers'  participation  in  information  systems  develop¬ 
ment."  [Ref.  13:  p.  84]  The  proliferation  of  micro  computers,  coupled  with  an 
increase  in  computer  literacy  throughout  the  work  force  has  brought  about  a 
phenomena  called  "end-user  computing."  End-user  computing  is  not  the  same 
as  end-user  involvement.  End-user  involvement  is  exactly  that,  involvement. 
That  is,  the  end-user  provides  the  developers  with  the  requirements,  feedback 
about  progress,  and  approval  of  the  final  system.  End-user  involvement  has  be- 
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come  a  requirement  of  all  systems  development  projects. «  On  the  other  hand, 
end-user  computing,  or  end-user  development9,  is  the  end-user  doing  the  devel¬ 
opment  of  the  entire  system  themselves,  with  or  without  assistance  from  IS  pro¬ 
fessionals. 


" ...end-user  development. ..Because  the  end-user  totally  controls  the  design  ef¬ 
fort,  there  is  little  need  to  go  through  a  traditional  systems  design  life  cycle. 
Moreover,  today,  end-users  are  much  more  sophisticated  about  information 
systems  than  they  were  in  the  1960s.  Therefore,  they  can  play  a  larger  role 
in  systems  design. 

End-user  development  does  not  necessarily  mean  total  end-user  con¬ 
trol  of  projects.  There  are  ways  in  which  end-user  development  can  be  as¬ 
sisted  by  professional  systems  personnel...."  [Ref.  16:  p.  423] 


Whether  it  be  development  or  involvement  in  development,  the  end-user  is  play¬ 
ing  a  greater  role  in  building  information  systems  to  satisfy  their  own  needs. 

Some  claim  that  end-user  computing  development  will  relieve  some  of  the 
huge  backlog10  of  systems  under  development.  Others  claim  end-user  computing 
will  only  make  the  backlog  worse  as  IS  professionals  have  to  repair  and  maintain 
user  "developed"  systems.  [Ref.  25:  pp.  233-234]  "In  one-fifth  of  data  processing 
shops,  85  percent  of  personnel  hours  are  allocated  to  maintenance,  leav  ing  little 
time  for  new  systems  development."  [Ref.  16:  p.  420] 


8  With  the  advent  of  Total  Quality  Management  end-user  involvement  has  received  increased 
emphasis.  The  end-user  is  the  'customer''  that  the  information  system,  and  consequently  the  sys¬ 
tem  s  developers,  must  satisfy. 

9  Some  even  differentiate  between  end-user  computing  and  end-user  development,  claiming 
that  end-user  computing  is  merely  using  the  computer,  and  end-user  developing  is  actually  devel¬ 
oping  computer-based  information  systems.  The  distinction  is  moot  in  this  context. 

10  The  explicit  backlog  is  that  set  of  applications  that  has  been  formally  stated  and  given  to 
IS  professionals  to  develop.  The  implicit,  sometimes  called  bidden",  backlog  is  that  set  ol  appli¬ 
cations  that  users  would  like,  but  haven’t  bothered  to  specify  because  the  explicit  backlog  i>  so 
huge. 
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End-user  computing  is  really  just  another  part  of  the  IS  puzzle  that  will 
need  to  be  nurtured,  managed,  encouraged  and  controlled.  "It  has  become  clear 
that  techniques  are  needed  for  guiding  end-user  computing  to  prevent  a  Tower 
of  Babel  from  springing  up  as  a  result  of  randomly  designed  data  and  redundant 
procedures."  [Ref.  15:  pp.  40-41]  Many  benefits  can  be  gained  from  a  carefully 
considered  and  nurtured  end-user  development  environment.  Conversely,  the 
risks  of  not  managing  end-user  development  are  also  great. 

(I )  Benefits.  "The  primary  benefits  of  end-user  development  are 
improved  requirements  determination,  reduced  application  backlog,  and  in¬ 
creased  end-user  participation  in  and  control  of  the  systems  development  proc¬ 
ess."  [Ref.  16:  p.  489]  Better  requirements  determination  would  occur  because  the 
users  are  the  ones  who  know  what  they  really  want.  If  the  end-users  develop  the 
system  themselves,  they  can  make  assumptions  and  compromises  appropriate  to 
the  importance  of  the  application,  without  having  to  explain  those  assumptions 
to  someone  unfamiliar  with  their  real  requirements.  In  effect,  end-users  practice 
a  development  methodology  called  "iterative  prototyping."  (More  about  that  in 
“c.  Prototyping”  on  page  48.) 

The  application  backlog,  both  explicit  and  implicit,  of  systems 
awaiting  development  will  decrease  as  more  users  develop  their  own  systems. 
Approximaieiy  60  percent  of  IS  professionals'  time  spent  maintaining  existing 
systems  is  spent  on  enhancements  [Ref.  18:  p.  71 1],  If  users  were  developing  their 
own  systems  to  satisfy  the  requirement  for  the  enhancement.  IS  professionals 
would  be  able  to  spend  more  time  building  new  systems.  The  backlog  is  reduced 
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in  two  ways,  end-user  development,  and  re-directing  IS  professional's  time  from 
maintenance  to  new  systems  development. 

Finally,  the  increased  end-user  participation  and  control  occurs 
as  the  end-users  become  increasingly  literate  about  systems  development.  The 
control  is  a  natural  by-product  of  increased  familiarity  and  a  "Gee,  I  can  do  that" 
attitude. 

(2)  Risks.  End-users  may  not  have  the  entire  picture  of  the  or¬ 
ganization's  functions.  Consequently  systems  they  develop  may  be  based  on  in¬ 
correct  assumptions  about  the  business  and  its  direction.  [Ref.  18:  p.  722].  The 
simplest  example  would  be  of  a  user  developing  a  system  to  manage  an  aspect  of 
the  organization  that  is  soon  to  be  divested,  closed  or  shut  down.  A  product  that 
is  soon  to  be  phased  out  is  one  such  situation.  In  this  case,  the  user's  development 
time  is  lost  as  well  as  the  opportunity  for  that  user  to  be  working  on  something 
else  of  real  value  to  the  organization. 

Another  risk  is  that  end-users  may  use  software  inappropriate 
to  their  needs.  [Ref.  18:  p.  722]  In  such  cases,  the  end-users'  development  time 
may  be  far  greater  than  needed.  They  may  find,  after  much  effort  has  been  ex¬ 
pended,  that  they  can't  accomplish  what  they  want  with  the  software  they've 
chosen.  Now  they  must  start  all  over  with  software  better  suited  to  their  partic¬ 
ular  application.  For  example,  someone  who  has  experience  with  a  particular 
spreadsheet  package  may  try  to  develop  a  database  application  using  that 
spreadsheet  package.  Although  most  spreadsheet  packages  have  some  database 
management  capabilities,  their  primary  focus  is  on  spreadsheet  applications,  and 
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any  database  capabilities  they  have  are  limited.* i  Database  management  pack¬ 
ages  are  particularly  well  suited  for  easy  development  of  database  applications. 
Much  time  can  be  lost  finding  work-around  solutions  in  the  spreadsheet  software 
to  problems  that  are  handled  as  a  matter  of  routine  by  database  management 
software. 

One  of  the  major  risks  associated  with  end-user  development  is 
that  standards  of  development,  learned  through  the  school  of  hard  knocks  by  IS 
professionals,  will  not  be  followed.  [Ref.  18:  p.  722]  Those  standards  could  be 
incorrectly  or  inadequately  applied  by  the  end-users.  An  end-user  developed  in¬ 
formation  system  that  contains  an  incomplete  data  dictionary  directory  system 
(DD  DS)i-  is  an  invitation  to  future  disaster.  A  DD  DS  that  does  not  contain 
all  data  elements  or  locations  of  these  elements,  when  used  to  locate  where  in  the 
IS  a  particular  data  element  is  used,  could  render  any  changes  made  based  on  the 
DD  DS  into  time  bombs.  Subsequent  users  would  faithfully  use  the  results  from 
the  system  never  realizing  that  its  accuracy  and  effectiveness  had  been  compro¬ 
mised  by  the  simple  but  incomplete  changc(s)  made  previously. 

Another  area  of  risk  is  that  of  the  stored  data  itself.  When  there 
are  many  user  developed  systems,  data  is  stored  in  all  of  them.  Which  of  these 


1 1  The  old  conventional  wisdom  about  trying  to  satisfy  two  or  more  objectives  inevitably 
leading  to  one  or  the  other  or  both  of  the  objectives  being  compromised  is  particularly  applicable 
to  software  packages. 

12  A  data  dictionary  is  a  dictionary  of  all  the  items  of  data  used  in  a  particular  information 
system.  It  shows  what  the  format  of  the  data  must  be,  and  what  the  data  element  represents.  1  or 
example,  SSN  is  9  numeric  characters  in  the  format  nnn-nn-nnnn,  representing  an  individual's  so¬ 
cial  security  number.  TTie  directory  portion  lists  each  and  every  use  of  that  data  clement  within  a 
system  thereby  helping  to  prevent  changes  to  the  system  from  being  incomplete,  for  example, 
changing  an  interest  rate  in  one  part  of  a  system  and  not  in  another.  Another  function  of  the  di¬ 
rectory  is  to  identify  who,  which  person  or  office,  controls  the  format  and  use  of  that  data  element. 
This  to  prevent  changes  that  may  impact  other  users  of  the  system. 
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disbursed  data  bases  has  the  current,  correct  information?  [Ref.  IK:  p.  722]  Who 
decides  which  system  is  the  one  to  solve  a  particular  business  problem?  How  does 
a  business  integrate  all  the  different  user  databases?  If  there  is  a  central  data¬ 
base,  who  is  allowed  access,  either  just  to  look  (read  only)  the  data,  or  to  change 
(read  write)  the  data?  These  questions  become  more  important  as  the  size  of  or¬ 
ganization  increases  and  there  is  a  corresponding  increase  in  end-user  develop¬ 
ment. 

Organizations  must  develop  new  policies  and  procedures  concerning  system 
development  standards,  training,  data  administration,  and  controls  to  man¬ 
age  end-user  computing  effectively.  [Ref.  16:  p.  490] 

a.  End-user  Computer  Literacy 

The  fact  that  computers  have  been  around  for  years,  and  have  infil¬ 
trated  our  schools  means  that  as  new  people  enter  the  work  force  they  do  so  with 
less  fear  of  computers  and  with  a  knowledge  of  what  computers  can  do  for  them. 
This  increased  literacy  is  bound  to  lead  to  an  increased  demand  for  computers 
and  computer-based  applications  that  help  knowledge  workers  do  their  jobs  more 
effectively.  For  example,  the  Naval  Academy  now  requires  every  student  to  have 
his  her  own  personal  computer.  This  will  have  increasingly  significant  impli¬ 
cations  for  what  those  students  expect  of  the  systems  they  use  in  the  fleet.  Fur¬ 
thermore,  those  computer  literate  students  will  form  a  talent  pool  in  the  Navy 
with  the  training  and  motivation  to  support  information  systems  projects  such  as 
OASIS  which  is  really  a  co-ordinated  "build  it  ourselves"  project. 
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b.  Increasing  Power  of  Micro  Computers 

It  is  no  secret  that  the  capability  of  a  mainframe  computer  of  15  years 
ago  is  now  contained  in  the  micro  computers  of  today.  The  speed  and  memory 
capacity  of  computer  hardware  has  increased  dramatically,  sometimes  even  dou¬ 
bling  in  a  few  short  years.  Software,  while  not  making  such  dramatic  leaps  as 
hardware  has  also  made  great  strides.  The  ease  with  which  users  can  learn  and 
effectively  use  most  software  packages  means  that  an  ^nd-user  must  no  longer 
hold  a  degree  in  computer  science.  These  two  trends  are  making  large  mainframe 
systems  virtually  obsolete  when  it  comes  to  satisfying  small  end-user  require¬ 
ments.  Using  to  maximum  advantage  the  increased  speed,  increased  memory  and 
more  powerful  software  available  in  modern  micro  computers  MUST  be  one  of 
the  principle  criteria  for  any  new  information  systems  development. 

c.  The  Proliferation  of  Micro  Computers 

Starting  with  the  purchase  of  the  Zenith  model  120,  micro  computers 
have  been  the  largest  growing  "population"  in  the  Navy.  One  can't  go  to  any 
command  without  finding  some  form  of  micro  computer.  Many  of  these  tools 
have  been  pushed  on  small  commands  by  higher  authority--"Hcre  you  are.  try  to 
use  it"  approach.  People  in  aviation  maintenance  tend  to  use  everything  at  their 
disposal  to  accomplish  their  jobs.  Their  resourcefulness  has  its  own  legendary 
subculture.  There  are  even  tales  of  entire  aircraft  hidden  away  as  spares.  Al¬ 
though  the  publicity  of  recent  years  has  changed  things  somewhat,  manipulating 
the  system  to  get  whatever  is  needed  to  accomplish  a  mission  is  still  practiced. 
Accordingly,  when  they  were  provided  another  tool,  it  was  only  a  matter  of  time 
before  they  used  it.  The  author  is  personally  familiar  with  applications  de\ eloped 
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by  people  in  OMAs  that  track  financial  data,  personnel  assignments,  training 
records,  tool  inventories,  technical  publications,  flight  hour  accounting,  as  well 
as  such  simple  things  as  pilot  qualifications.  Additionally,  information  systems 
have  been  and  are  being  developed  by  students  here  at  the  Naval  Postgraduate 
School,  not  to  mention  electronic  bulletin  boards  that  have  sprung  up  for  the  ex¬ 
change  of  specific  applications  that  have  been  developed. 

d.  Development  Backlog 

As  has  been  previously  mentioned,  a  backlog  of  systems  awaits  de¬ 
velopment.  The  size  of  this  backlog  is  typically  measured  in  years.  The  most 
common  range  is  three  to  seven  years.  What  that  means  is  that  if  one  were  to 
give  a  development  project  to  a  developer  today,  he  would  not  even  start  for  at 
least  three  years.  To  someone  with  a  problem,  such  a  delay  is  unacceptable.  He 
will  find  another  way  to  solve  the  problem.  "Users  are  accustomed  to  achieving 
goals  in  their  own  fields  with  a  consistency  that  is  unheard  of  in  the  software 
world."  [Ref.  4:  p.  4]  Consequently,  many  frustrated  end-users  resorted  to  build¬ 
ing  their  own  systems,  becoming  computer  literate  along  the  way.  (Incidentally, 
the  end-users  in  the  fleet  arc  used  to  meeting  performance  goals,  e.g.,  readiness. 
MC.  FMC,  training  levels,  pilot  training  rate,  far  above  anything  that  any  infor¬ 
mation  system  provided  or  promised  them  has  actually  met.) 

e.  Concerns  of  IS  Professionals 

End-user  computing  can  be  perceived  as  both  a  threat  to  and  a  relief 
to  IS  professionals.  On  the  one  hand,  their  bad  reputation  for  being  late,  over 
budget  and  incomplete  with  IS  projects  can  only  be  helped  if  they  have  less 
backlog.  On  the  other  hand,  if  the  end-users  become  proficient  at  developing 
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applications,  IS  professionals  may  see  themselves  being  replaced.  The  reality  of 
the  situation  is  that  the  end-user  doesn't  want  the  IS  professional's  job;  he  just 
wants  the  tools  to  do  his  own  job  better.  There  will  always  be  a  need  for  a  "better 
mouse  trap",  and  even  for  the  tools  with  which  to  build  the  better  trap. 

Since  information  has  achieved  status  as  a  corporate  resource,  it  must 
be  protected  as  a  resource.  The  security  of  the  information  is  as  important  as  the 
security  of  any  other  corporate  asset.  Proliferating  micro  computers  make  main¬ 
taining  data,  information  security  particularly  difficult.  A  computer  on  every 
desktop  provides  the  means  of  obtaining  corporate  secrets  to  any  one  who  knows 
how  to  use  the  computer.  A  comprehensive  security  plan  is  now  necessary  to 
protect  both  the  physical  and  electronic  assets  of  the  organization. 

A  closely  related  issue  is  that  of  data  integrity.  Who  is  allowed  to 
change  the  data  is  particularly  important,  along  with  the  timing  and  frequency 
of  those  changes.  If  two  or  more  different  copies  of  information  somehow  man¬ 
age  to  exist  at  the  same  time,  which  one  is  correct  or  most  current  can  be  a  par¬ 
ticularly  difficult  problem  to  solve.  It  is  only  exacerbated  with  each  additional 
micro  computer.  A  closely  related  issue  of  ownership  must  also  be  addressed. 
The  user,  i.e.,  person,  office,  or  command,  that  "owns"  a  particular  bit  of  data  or 

information  is  entirely  responsible  for  that  information.  He 

•  establishes  the  requirement  for  that  information. 

•  determines  the  format  of  that  information, 

•  maintains  the  description  and  definition  of  that  information. 

•  authorizes  access  to  and  use  of  the  information, 

•  and  authorizes  changes  to  an\  of  the  above. 
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The  concept  of  information  ownership  is  important  when  designing  an  informa¬ 
tion  system.  Designers  must  work  closely  with  information  owners  to  ensure  that 
the  owners'  requirements  are  met,  while  at  the  same  time  impressing  on  the 
owners  the  potential  impact  on  the  IS  of  any  changes  they,  the  owners,  might 
make.  Changing  the  format  of  a  single  data  element  such  as  a  date  could  require 
changing  storage  formats,  forms,  and  users'  habits;  moreover,  the  change  will 
have  ramifications  proliferating  throughout  the  organization.  Information  own¬ 
ership  carries  the  responsibility  of  deliberate  change,  if  any,  and  long  term  sta¬ 
bility. 

Another  very  important  issue  is  data  administration.  "Data  adminis¬ 
tration.. As  concerned  with  the  planning,  administrative,  and  control  functions  for 
managing  information. ..It  is  responsible  for  policies  and  procedures  through 
which  data  can  be  managed  as  a  companywide  resource."  [Ref.  16:  p.  646]  This 
is  closely  related  to  the  data  dictionary  directory  system  discussed  earlier.  "Data 
administration  is  more  organizationally  or  business  oriented...."  [Ref.  16:  p.  645] 
Additionally,  data  and  information,  recognized  as  a  resource,  are  being  treated 
as  a  resource  of  the  entire  organization,  not  just  one  part  of  that  organization. 

The  most  fundamental  principle  of  data  administration  is  that  all  data  are  the 
property  of  the  organization  as  a  whole.  They  cannot  belong  exclusively  to 
any  one  business  area  or  organizational  unit.  All  data  are  to  be  made  avail¬ 
able  to  any  group  that  requires  them  to  fulfill  its  mission.  [Ref.  16:  p.  645] 

The  last  concern  of  IS  professionals  to  be  discussed  is  that  of  end-user 
development  running  rampant  with  no  guidance,  no  controls  and  few  if  any  ap¬ 
plied  standards.  As  discussed  in  “(2)  Risks"  on  page  40.  these  standards  can 
have  a  significant  impact  on  the  system's  performance  and  accuracy.  IS  profes- 


46 


sionals  fear  that  end-users  will  buy  anything  and  everything.  Whether  because 
it  is  the  latest  computer  fad  or  because  the  end-users  don't  know  any  better  does 
not  really  matter.  The  analogy  of  child  in  a  candy  store  is  apropos.  The  solution, 
as  with  the  child,  is  to  allow  the  growth  of  end-user  computing  within  limits  as 
long  as  the  organization's  missions  and  problems  are  being  addressed  by  the 
growth.  This  concern  may  in  fact  not  be  long-lived.  As  end-users  become  more 
IS  literate,  they  will  be  less  likely  to  buy  anything  more  than  a  solution  to  their 
particular  problem  [Ref.  37], 

5.  Techniques  and  Methods 

Three  techniques  and  methods  arc  relevant  to  the  development  of  OASIS. 
They  are  Structured  Analysis  and  Design  techniques,  Information  Engineering, 
and  Prototyping. 

a.  Structured  Techniques 

Since  TPSs  were  the  first  step  in  the  evolution  of  computer-based  in¬ 
formation  systems,  a  large  body  of  knowledge  exists  today  about  how  to  design, 
build  and  implement  such  systems.  A  variety  of  methods  and  techniques  to  an¬ 
alyze  and  design  systems,  as  well  as  a  plethora  of  designers,  and  even  entire 
businesses,  are  now  available  to  support  TPS  development.  [Refs.  2.  15,  39.  40  , 
and  41]  Most  emphasize  the  information  requirements  of  an  organization,  and 
take  a  very  formal,  rigorous  approach  to  modeling  the  existing  systems.  Several 
well  known  advocates  are  DeMarco  [Ref.  4].  Yourdon  [Ref.  39).  and  Page-Jones 
[Ref.  40], 
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b.  Information  Engineering 

The  second  technique,  in  fact  almost  a  philosophy,  is  Information 
Engineering  (IE).  The  term  "information  engineering"  implies  the  rigor  and  dis¬ 
cipline  associated  with  the  more  traditional  engineering  professions  (such  as  civil, 
mechanical,  chemical  and  electrical  engineering).  In  fact,  over  the  past  decade, 
the  development  of  information  systems  has  progressed  from  the  "art  of  pro¬ 
gramming"  to  a  set  of  formal,  rigorous  disciplined  techniques.  Now,  "the  term 
information  engineering  refers  to  a  set  of  interrelated  disciplines  which  are  needed 
to  build  a  computerized  enterprise  based  on  data  systems.. .The  basic  premise  of 
information  engineering  is  that  data  lie  at  the  center  of  modern  data  processing." 
[Ref.  42:  p.  92]  IE  had  its  origins  with  IBM's  Business  Systems  Planning  program 
in  1970  [Ref.  43].  Among  the  well  known  advocates  of  IE  today  are  James 
Martin,  Texas  Instruments,  and  Clive  Finkelstein.  They  all  recommend  concen¬ 
trating  on  the  organization's  missions  and  goals  instead  of  the  existing  systems, 
evaluating  the  data  required  to  achieve  those  goals,  and  building  information 
systems  to  provide  and  manage  that  data.  In  some  cases,  existing  systems  can 
be  integrated  into  the  otherwise  all  new  IS.  (This  is  what  I  recommend  for 
NALCOMIS  OMA.  We  have  wasted  enough  time  and  money  on  it  already. 
Let's  not  throw  more  at  it.  Instead,  treat  it  as  a  'sunk'  cost  and  get  on  with  what 
OMAs  really  need.  Use  what  can  be  used  from  it,  but  most  importantly. 
LEARN  from  the  debacle  so  we  don't  repeat  it!) 

c.  Prototyping 

A  prototype  is  a  one-of-a-kind  type  of  item  built  to  determine  what 
is  really  needed.  Prototyping  then  is  the  process  of  building  a  prototype,  generally 
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with  the  idea,  either  implicit  or  explicit,  of  throwing  it  away  once  the  real  re¬ 
quirements  have  been  determined.  Prototyping  provides  a  way  to  "buy"  infor¬ 
mation  from  the  end-users  about  what  they  really  want,  "...plan  to  throw  one 
away;  you  will,  anyhow."  [Ref.  44:  p.  116]  There  are  now  two  approaches  to 
prototyping,  throwaway  and  evolutionary  [Ref.  22:  p.  150].  The  evolutionary  dif¬ 
fers  from  the  traditional  throwaway  in  that  it  is  intended  to  evolve,  through  as 
many  iterations  as  necessary,  into  a  deliverable  system.  There  are  several  key 
benefits  of  prototyping— the  iterations  occur  quickly;  the  users  provide  feedback 
on  each  iteration,  and  thereby  stay  involved  in  the  development;  and  the  cost  is 
typically  lower  than  traditional  life  cycle  development  [Ref.  22:  p.  152],  A  ben¬ 
efit  of  particular  value  to  developing  OASIS  is  a  situation  with  many  geograph¬ 
ically  disbursed  users.  In  that  situation,  a  prototype  allows  you  to  "get  the  idea 
out"  to  many  of  them,  keeping  many  of  them  involved,  and  avoiding  some  of  the 
"just  another  program  form  headquarters"  acceptance  problems. 

D.  INFORMATION  SYSTEMS  IN  AVIATION  MAINTENANCE 
1 .  Background 

Information  systems  intended  to  make  maintaining  aircraft  more  effective 
and  efficient  have  been  under  development  for  years.  The  Maintenance  Data 
Collection  System  (MDCS)  was  developed  to  "insure  that  basic  data  generated 
by  maintenance  personnel  are  recorded  once,  and  only  once,  and  that  the  system 
(not  the  maintenance  activity)  thereafter  provides  information  to  all  who  have  a 
need  for  it  in  such  forms  as  may  be  useful."  [Ref.  8:  p.  1-8]  The  MDCS  became 
the  Maintenance  Data  System  (MDS)  [Ref.  45].  Within  this  system  coded  data 
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describing  every  maintenance  action  is  recorded  on  a  form13.  These  forms  are 
then  collected,  checked  for  accuracy  and  conformance  to  NAMP  standards  by 
an  analyst  at  the  OMA,  and  taken  to  a  Data  Services  Facility  (DSF)  to  have  the 
data  on  them  keypunched,  i.e.,  entered  into  a  computer  system  via  keyboard. 

The  volume  of  these  transactions  is  very  large,  and  processing  large  vol¬ 
umes  of  data  is  "the  aim  of  record-keeping  systems."  [Ref.  18:  p.  446]  Consider 
a  hypothetical  situation:  there  are  300  OMAs,  ten  aircraft  per  OMA,  and  each 
aircraft  has,  on  average,  five  transactions  associated  with  it  daily.  That  would 
amount  to  15,000  per  day,  and  would  not  account  for  fluctuation.  In  a  year  there 
w'ould  be  5,375,000  transactions  to  be  collected,  stored,  sorted  and  summarized. 
This  hypothetical  situation  is  less  than  what  really  occurs.  There  are  really  over 
400  OMAs,  and  an  aircraft  with  only  five  documented  transactions  per  day  is  a 
very  rare  aircraft  indeed.  The  MDS,  of  necessity,  became  a  management  re¬ 
porting  system,  which  at  pre-specified  intervals  produces  pre-defined  reports 
based  on  the  data  collected  and  stored  by  its  supporting  TPS  [Ref.  13:  pp.  71-72]. 
It  produces  daily,  weekly  and  monthly  listings  of  all  transactions,  and  summaries 
of  those  transactions  for  the  OMAs  &  IMAs.  When  the  stored  data  has  been 
verified  and  corrected,  summary  reports  are  sent  upline  to  higher  authorities. 

NAVAIR  realized  that  the  raw7  data  being  collected  in  support  of  aircraft 
maintenance  was  outstripping  the  ability  of  managers  to  assimilate  it,  and  the 
sheer  volume  of  data  was  making  the  reports  and  summaries  less  and  less  timely, 

13  Even  though  it's  called  the  MAINTENANCE!  Data  System,  the  MDS  collects  logistics  and 
operations  data  as  well.  Several  forms  are  used  in  the  MDS,  including  the  Maintenance  Action 
form  (MAE),  the  Support  Action  Form  (SAE).  and  the  Naval  1  light  Information  Record 
(NAVI- TIR). 
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and  therefore  of  less  value  for  making  time-critical  decisions.  The  batch  proc¬ 
essing14  TPS  just  was  not  meeting  the  needs  of  all  its  intended  users.  In  1974,  a 
Management  Information  System  was  conceived  to  allow  data  to  be  collected 
only  once,  and  make  information,  instead  of  simply  data,  available  to  those  who 
needed  it,  both  the  operating  units  and  higher  authorities.  The  Naval  Aviation 
Logistics  Command  Management  Information  System  (NALCOMIS),  was  in¬ 
tended  as  "a  modern  computer  system  to  provide  timely  and  accurate  aircraft 
maintenance,  operations,  and  logistics  data."  [Ref.  46:  p.  1]  NALCOMIS  was 
aimed  at  supporting  "day-to-day  maintenance  and  supply  activities,"  i.e.,  OMAs. 
IMAs,  and  Supply  Support  Centers  (SSCs)  in  addition  to  satisfying  upline  re¬ 
porting  requirements  of  Navy  and  Department  of  Defense  Program  managers 
[Ref.  46:  pp.  3-4].  Given  the  enormity  of  the  tasks  it  was  to  perform. 
NALCOMIS  was  broken  into  three  phases  [Ref.  11:  pp.  3-4].  Phase  I  was  an 
interim  system,  implemented  at  only  a  few  activities,  called  NALCOMIS  Rc- 
pairablcs  Management  Module  (NRMM)  [Ref.  11:  p.  3].  Phase  II  addresses  the 
information  needs  of  IMAs  and  SSCs,  and  provides  external  interfaces  to  other 
related  information  systems  such  as  AV-3M  (Aviation  Maintenance  and  Material 
Management),  SUADPS  (Shipboard  Uniform  Automated  Data  Processing  Sys¬ 
tem),  UADPS  (Uniform  Automated  Data  Processing  System),  and  of  course. 
NALCOMIS  DMA  [Ref.  47:  pp.  36-37],  Phase  III  of  NALCOMIS,  also  called 
NALCOMIS  OMA,  was  intended  to  automate  the  OMAs  [Ref.  48:  p.  3-1], 

14  Batch  processing  occurs  when  "all  data  and  transactions  are  coded  and  collected  into  groups 
(hatches)  before  processing "  | Ref.  IS:  p.  306| 
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2.  Current  Situation 


Many  information  systems  are  intended  to  support  the  three  levels  of 
aviation  maintenance.  The  Naval  Air  Systems  Command  (NAVA1R)  is  the 
principle  sponsor  of  such  systems.!5  The  majority  of  information  systems  devel¬ 
oped  or  planned  for  aviation  maintenance  have  been  large  systems,  i.e..  requiring 
a  mainframe  or  at  least  a  mini  computer.  Until  micro  computers  became  capable 
of  performing  some  of  the  required  functions,  building  large  systems  was  virtually 
the  only  way  aviation  maintenance  could  hope  to  reap  benefits  of  computerized 
information  systems. 

Unfortunately,  "...large  systems  development  projects  are  often  30  percent 
over  budget  and  require  50  percent  more  time  than  the  early  estimates  developed 
in  the  project  plan  of  a  traditional  systems  life  cycle.  Unfortunately,  large-scale 
projects  have  dev  eloped  a  reputation  for  being  much  more  costly,  and  much  later, 
than  expected."  [Ref.  16:  p.  418] 

NAVAIRs  Component  Information  Management  Plan  (C1MP)  [Ref. 
49]  lists  all  information  systems  currently  being  planned  or  developed  to  support 
NAVAIR  missions.  The  four  "functional  areas"  for  which  information  systems 

are  being  developed  are: 

•  Logistics, 

•  Systems  &  Engineering, 

•  Contracts,  Administration  and  Business,  and 

•  Support  Systems. 

15  The  Naval  Supply  Systems  Command  (NAYSCP)  has  a  vested  interest  in  such  s\ stems 
since  NAVSL’P  is  tasked  with  material  support  of  av  iation  activities. 
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As  it  turns  out,  "the  majority  of  NAVAIR's  current  major  ISs  reside  in  the  avi¬ 
ation  logistics  functional  area."  [Ref.  49:  p.  1-11]  This  is  not  surprising,  since 
NAVAIR's  primary  mission  "is  to  provide  for  the  full  range  of  material  support 
needs  of  the  operating  forces  of  the  Navy  for  aeronautical  weapons  systems." 
[Ref.  49:  p.  1-6] 

Within  the  Logistics  functional  area,  there  are  26  different  information 
systems  described  in  the  CIMP.  They  include  local  area  networks  (LANs)  for 
specific  commands,  systems  dedicated  to  supporting  one  level  of  maintenance, 
systems  designed  to  address  one  aspect  of  aviation  logistics  support  at  all  three 
levels  of  maintenance,  and  systems  with  requirements  to  provide  extensive  sup¬ 
port  throughout  all  of  NAVAIR  and  the  operating  forces.  Of  those  systems, 
three  can  have  a  direct  impact  on  an  OMA's  ability  to  perform  its  missions.  They 
are: 

•  Aviation  Training  Support  System— Phase  II  (ATSS  II), 

•  Naval  Aviation  Logistics  Command  Information  Systems  (NALCOMIS). 
and 

•  Support  Equipment  Resources  Management  Information  Svstem 
(SERMIS). 

ATSS  II  "provides  Fleet  Readiness  Squadrons  (FRS)  with  an  automated  man¬ 
agement  support  system  to  improve  the  efficiency  of  all  aircrew  and  maintenance 
training."  [Ref.  49:  p.  LOG- 10]  From  the  OMA  point  of  view,  ATSS  II  provides 
them  with  a  record-keeping  capability  for  the  training  records  of  their  personnel. 
The  primary  intent  however  is  to  help  manage  the  training  evolution  itself,  and 
only  peripherally  to  support  the  OMAs.  SERMIS  is  a  system  intended  to  help 
Support  Equipment  Controlling  Activ  ities  (SECAs)  perform  their  mission  of  al- 
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locating,  inventorying  and  reworking  support  equipment  used  by  all  aviation  ac¬ 
tivities  in  the  Navy.  [Ref.  49:  p.  LOG-101]  Again,  accomplishing  an  OMA's 
missions  is  not  the  real  purpose.  NALCOMIS  however,  was  intended  from  its 
inception  to  satisfy  the  information  needs  of  organizational  and  intermediate 
maintenance  activities  throughout  the  Navy. 

Of  those  described,  only  NALCOMIS  was  intended  to  provide  aviation 

logistics,  material  management  and  administrative  support  to  OMAs. 

There  are  four  primary  objectives  of  NALCOMIS,  each  of  which  has 
a  major  impact  on  the  mission  capability  and  overall  personnel  effectiveness 
at  the  Organizational  Maintenance  Activity  (OMA),  Intermediate  Mainte¬ 
nance  Activity  (IMA),  and  Supply  Support  Center  (SSC)  levels  in  support 
of  the  Naval  Aviation  Maintenance  Program  (NAMP). 

The  four  objectives  are: 

(1)  Improved  aircraft  mission  capability. 

(2)  Improved  aircraft  maintenance  and  supply  support. 

(3)  Improved  upline  reporting  to  satisfy  Navy  and  Department 
of  Defense  (DOD)  program  requirements. 

(4)  Modernized  management  support.  [Ref.  49  :  p.  LOG-81] 

NALCOMIS  is  a  very  large  system.  The  estimated  total  dollar  require¬ 
ment  for  the  period  FY88--FY94  is  S204.333,000.  When  one  recalls  the  reasons 
NALCOMIS  came  into  being,  and  the  number  of  transactions  it  was  intended  to 
handle,  large  was  inevitable. 

Large  systems  such  as  NALCOMIS,  while  seeming  to  provide  an  overall 
integrated  system  that  realizes  economies  of  scale,  have  by  their  very  size  not  been 
able  to  take  advantage  of  the  tremendous  increases  in  computer  speed  and  mem¬ 
ory,  or  of  the  decrease  in  physical  size  that  have  occurred.  For  example,  when 
NALCOMIS  was  first  envisioned,  who  could  have  realistically  thought  that  15 
years  later,  all  of  the  requirements  could  be  satisfied  by  hardware  and  software 
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sitting  on  someone's  desk.  Such  is  the  case,  yet  because  of  the  magnitude  of  the 
project  in  1976,  and  the  technology  then  available,  a  development  time  of  15 
years  was  unavoidable.  If  NALCOM1S  were  the  only  example  of  large  systems 
development,  then  the  fact  that  it  has  taken  so  long  to  field  could  be  attributed 
to  poor  project  management.  Such  is  not  the  case.  In  fact,  the  entire  information 
systems  industry  has  been  plagued  by  projects  that  are  late,  are  over  budget  and 
don't  perform  as  intended.  "A  construction  job  is  considered  a  debacle  if  it 
overruns  six  percent."  [Ref.  4:  p.  4]  It  is  possible  that  such  projects  were  too 
ambitious  from  the  outset.  However,  this  author  believes  that  the  ambitious  goals 
were  not  the  problem,  but  that  technology  outstripped  our  ability  to  take  advan¬ 
tage  of  it. 

3.  Previous  Recommendations  and  Requirements 

McCaffrey  [Ref.  6],  explored  the  use  of  an  expert  system  for  discrepancy- 
scheduling  with  NALCOMIS.  He  concluded  that  an  ES  was  both  feasible  and 
desirable.  However,  one  of  his  premises  was  that  the  system  would  run  on  the 
same  hardware  as  NALCOMIS  OMA.  At  the  time,  (1985),  NALCOMIS  OMA 
was  scheduled  to  be  implemented  on  a  Honeywell  mini-computer.  McCaffrey's 
ES  was  intended  to  be  run  only  two  to  three  times  a  day,  and  because  of  the 
processing  demands  of  the  ES,  would  lockout  other  NALCOMIS  processes  while 
running. 

Allen  &  McSwain,  in  their  thesis  [Ref.  7]  carry  McCaffrey's  work  further 
and  propose  something  more  than  just  an  ES,  specifically  a  DSS  ES  for  the  MC 
arena.  They  offer  a  set  of  design,  evaluation  and  implementation  criteria.  They 
recommend  a  prototype  that  addresses  the  problem  of  assigning  aircraft  to  par- 


55 


ticular  missions  on  the  flight  schedule  based  on  the  needs  of  the  mission,  and  the 
mission  capability  of  the  aircraft. 

E.  SUMMARY 

In  summary,  information  systems  have  evolved  from  manual  transaction 
processing  systems  through  computerized  transaction  processing  systems,  man¬ 
agement  information  systems,  decision  support  systems  and  expert  systems  to  the 
integrated  concept  of  today  where  an  information  system  may  include  any  com¬ 
bination  of  them.  Information  is  now  considered  a  resource.  Information  sys¬ 
tems  are  the  tools  with  which  to  manage  that  resource  while  focusing  on 
accomplishing  an  activities  goals. 

Advances  in  technology  have  made  the  laptop  of  today  the  equivalent  of  the 
mainframe  of  15  years  ago.  Software  development  has  evolved  to  the  degree  that 
many  consider  it  a  field  of  engineering.  Computer  and  information  technology 
has  moved  from  the  back  room  to  front  office.  Developing  information  systems 
has  become  less  "art"  and  more  "science."  That  science  is  being  applied  in  many 
ways  to  benefit  and  improve  the  uses  and  development  of  information  systems. 

End-users  are  becoming  increasingly  willing  and  able  to  develop  their  own 
information  systems.  The  tools  for  them  to  do  so  are  readily  available.  So  readily 
available  that  managing  end-user  computing  has  become  a  concern  of  informa¬ 
tion  systems  professionals. 

Decision  support  systems  and  expert  systems  have  become  significant  parts 
of  many  organizations  information  management.  In  fact,  use  of  ESs  is  growing 
so  rapidly  that  an  organization  that  ignores  them  risks  being  at  a  competitive 
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disadvantage.  The  consistent  leveraging  of  expertise  is  allowing  organizations 
that  do  use  ESs  to  produce  better  products  and  provide  better  services. 

In  spite  of  all  the  advances  in  computer  and  information  technology,  OMAs 
still  do  not  have  an  information  system.  In  spite  of  all  the  effort  and  money  spent 
to  get  them  one,  they  still  lack  the  modern  tool  to  effectively  and  efficiently 
manage  their  information  as  resource.  Not  only  must  managers  at  OMAs  man¬ 
age  huge  piles  of  paper  searching  for  necessary  but  sometimes  obscure  informa¬ 
tion,  but  in  this  era  of  diminishing  funding,  they  may  have  to  manage  with  fewer 
experts  as  well.  OASIS  will  fill  this  growing  gap. 
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IV.  PROPOSED  INFORMATION  SYSTEM,  OASIS 


This  chapter  comprises  the  actual  proposal  for  the  Organizational  Activity 
Strategic  Information  System  (OASIS).  First  the  strategic  and  functional  re¬ 
quirements  will  be  discussed,  then  the  actual  modules  that  should  be  imple¬ 
mented,  then  a  preliminary  implementation  plan,  and  finally  a  discussion  of 
potential  problems  and  benefits. 

A.  STRATEGIC  AND  FUNCTIONAL  GOALS 

The  adage  "If  you  aim  at  nothing,  you'll  hit  it  every  time?"  certain!}'  applies 
to  organizations.  An  organization  needs  to  have  some  idea  of  what  it  is  trying  to 
do,  and  how  it  plans  to  do  it.  This  "direction"  of  the  organization  should  be  ex¬ 
plicit.  In  large  organizations,  such  as  the  Navy,  determining  this  direction  is 
normally  a  formal  planning  process.  The  planning  process  should  provide  an 
organization  with  a  statement  of  its  goals  in  a  form  that  can  be  used  throughout 
the  organization,  a  statement  of  its  current  situation  relative  to  those  goals,  and 
a  detailed  plan  of  how  it  is  going  to  achiev  e  those  goals.  There  arc  normally  three 

steps  to  this  process  and  they  are: 

•  Goal  Formulation, 

•  Current  Situation  Analysis,  and 

•  Plan  Formulation. 

Goal  formulation  encompasses  three  basic  activities;  "...understanding  the 
organization's  purpose,  defining  its  mission,  and  establishing  the  objectives  that 
translate  the  mission  into  concrete  terms."  [Ref.  17:  p.  123]  Current  situation 
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analysis  is  an  evaluation  of  where  the  organization  is  now  in  relation  to  its  goals, 
any  identifiable  thrcat(s)  to  achieving  its  goals,  and  any  identifiable  opportunities 
the  organization  should  exploit.  [Ref.  17:  pp.  124-125]  Plan  formulation  is  where 
alternative  ways  of  achieving  the  organization's  goals  arc  evaluated  and  the  one 
the  organization  will  follow  is  identified  and  promulgated  throughout  the  organ¬ 
ization.  [Ref.  17:  pp.  127-128] 

An  OMA's  goals  arc  derived  from  the  objective  of  the  NAMP,  which  "is  to 
achieve  and  continually  upgrade  the  readiness  and  safety  standards  established 

by  CNO."  [Ref  9:  p.  1]  Those  goals  are  to: 

•  Increase  efficient  and  economical  management  of  human,  monetary,  and 
material  resources, 

•  Ensure  the  maintenance,  manufacture,  and  calibration  of  aeronautical 
equipment  and  material  occurs  at  the  level  of  maintenance  that  will  ensure 
optimum  use  of  resources, 

•  Ensure  the  protection  of  weapons  systems  components  from  corrosive  ele¬ 
ments  through  an  active  corrosion  prevention  program. 

•  Ensure  the  optimum  application  of  a  systematic  planned  maintenance  pro¬ 
gram,  and 

•  Collect,  analyze,  and  use  pertinent  data  to  effectively  improve  material 
readiness  and  safety.  [Ref.  9:  p.  1] 

Of  these,  the  middle  three  are  simply  more  specific  sub-goals  of  the  first.  The 
last  is  the  traditional  goal  of  an  IS,  collecting  and  analyzing  data.  Placing  it  last 
should  serve  to  emphasize  that  an  information  system  is  the  tool  for  managing  the 
information  needed  to  achieve  all  the  other  goals,  and  nothing  more. 

The  most  important  of  the  NAMP  goals  is  the  first.  It  identifies  the  three 
main  categories  of  resources  that  must  be  managed.  Human  includes  aircrew, 
maintenance  and  support  personnel.  AND  their  training;  "monetarv  at  the 
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OMA  is  primarily  concerned  with  operating  target  (OPTAR16)  management:  and 
"material"  includes  aircraft,  ordnance,  parts,  supplies,  publications  and  informa¬ 
tion.  This  division  will  form  the  basis  for  the  proposed  modules  of  OASIS. 

A  distinction  needs  to  be  made  between  the  goals  of  an  OMA  and  the  goals 
of  OASIS.  An  OMA's  goal  is  to  achieve  and  maintain  CNO  standards  of  read¬ 
iness  and  safety.  OASIS's  goal  is  to  help  OMA  maintenance  professionals  man¬ 
age  all  their  resources  effectively  so  that  the  OMA's  goal  can  be  achieved. 
However,  OASIS  is  an  information  system  and  as  such  OASIS  must  try  to 
achieve  the  applicable  goals  published  for  all  Navy  information  systems.  Those 
goals  are  promulgated  in  SECNAVINST  5230.10.  the  IRSTRATPLAN  [Ref. 
50],  Although  they  are  not  the  underlying  reasons  for  developing  OASIS,  the 
IRSTRATPLAN  goals  for  information  systems  must  be  considered.  The  sewn 

goals  of  the  DON  IRSTRATPLAN  are: 

•  "To  enhance  the  productivity  of  DON  components." 

•  "Make  information  technology  a  force  multiplier." 

•  "Improve  responsiveness  to  mission  requirements.'' 

•  "Streamline  the  computer  resource  and  information  systems  acquisition 
process." 

•  "Provide  quality  equipment,  software  and  serv  ices." 

•  "Protect  DON  resources." 

•  "Maximize  the  exploitation  of  technology."  [Ref.  50:  end.  (!),  pp.  13- IS] 

Hav  ing  established  the  goals  of  OMAs  and  OASIS,  the  next  step  is  to  ev  alu¬ 
ate  the  current  situation,  specifically  with  regard  to  information  systems  for 

16  An  OPTAR  is  an  operating  target  that  an  activity  is  given  periodically  by  its  tv  pe  or  fleet 
commander.  It  is  an  administrativ  e  limit  on  the  amount  of  funds  the  activate  can  obligate  from  the 
operations  and  maintenance.  Navv  (O&M.N)  appropriation.  OMA  s  typically  receive  an  OPTAR 
for  flight  operations,  and  an  OP  IAR  for  aviation  licet  maintenance  |  Ref  10:  p  6- 1 32 1 


OMAs.  Even  though  a  more  thorough  evaluation  might  be  thought  necessary 
by  some,  the  result  will  be  the  same.  That  is,  OMAs  do  not  have  an  information 
system  with  which  to  effectively  manage  information  about  all  their  resources. 
They  may  have  parts  of  one,  but  not  all  OMAs  have  the  same  parts,  and  not  all 
parts  are  the  same.  In  other  words,  OMA  "A"  may  have  developed  a  spreadsheet 
to  help  track  and  manage  its  fuel  expenditures,  while  OMA  "B"  may  have  devel¬ 
oped  a  database  to  help  track  and  manage  the  qualifications  of  its  aircrew. 
Further  evaluation  should  be  done  to  establish  exactly  what  has  been  developed, 
and  the  applicability  of  those  applications  to  all  OMAs.  Such  a  study  should  also 
assess  the  hardware  currently  held  by  OMAs,  so  that  budgeting  to  acquire  any 
additional  hardware  could  begin  immediately. 

Since  so  much  effort  has  already  been  expended  developing  functional  re¬ 
quirements  for  NALCOM1S,  they  should  be  reviewed  and  evaluated  with  the 
end-users  for  applicability  to  OASIS.  A  brief  list  of  the  NALCOMIS  functions 

is  extracted  from  Reference  46,  page  4,  and  repeated  here: 

•  "The  proper  identification  of  maintenance  problems,  along  with  the  right 
maintenance  skill  and  material  to  do  the  repairs...." 

•  "Verify  repair  completion  and  determine  material  readiness." 

•  Make  the  current  workload  readily  visible  to  maintenance  managers. 

•  Establish  a  maintenance  schedule  based  on  the  "priorities  of  available  re¬ 
sources  including  skills,  worker  hours,  material  and  support  equipment." 

•  Assist  in  the  assignment  of  "properly  skilled  persons  to  p  \  form  maintenance 
actions." 

•  Provide  supply  and  OMA  maintenance  managers  with  'timely  notification" 
of  material  requisitioning  and  delivery. 

•  Provide  OMA  maintenance  managers  with  the  "availability  and  operability 
of  aircraft." 

•  Provide  summarized  overall  status  "for  management  visibility  in  a  timely 
fashion." 
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•  Provide  for  tracking  inventories  of  "repairable  components,  support  equip¬ 
ment,  component  parts,  requisitions,  personnel,  and  maintenance  capabili¬ 
ties." 

The  next  section  provides  a  brief  review  of  the  NALCOM1S  subsystems.  The 
following  sections  will  describe  the  modules  of  OASIS,  and  address  the  last  step 
in  the  planning  process,  formulating  a  plan  composed  of  the  objectives  that  add 
substance  to  the  goals,  i.e.,  the  specific  functions  that  OASIS  will  perform. 

B.  NALCOMIS 

To  support  the  functions  described  in  the  previous  section, 
NALCOMIS  OM A  was  divided  into  ten  subsystems.  The  brief  descriptions  in 
the  following  sections  are  extracted  from  Reference  46,  pages  9-10. 

1.  Data  Base  Maintenance 

This  subsystem  was  to  be  the  data  base  housekeeper.  It  "establishes  and 
maintains  the  nonvolatile  data  within  NALCOMIS  and  performs  local  data  base 
support  functions  for  all  subsystems."  [Ref.  46:  p.  9]  Such  functions  as  purging 
no  longer  needed  data  and  transferring  data  to  historical  archives  were  included. 

2.  Flight  Activity 

This  subsystem  was  to  collect  flight  hour  data  for  use  by  other  subsys¬ 
tems.  The  data  collected  is  that  which  is  now  collected  on  the  Naval  Aircraft 
Flight  Record  (NAVFL1R)  form.  This  data  was  to  be  used  to  track  aeronautical 
equipment  usage  for  planning  scheduled  maintenance. 

3.  Maintenance  Activity 

This  subsystem  was  intended  to  "perform  fully  automated  processing  of 
the  Visual  Information  Display  System  Maintenance  Action  Form 
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(VI DS,  MAF)."  [Ref.  46:  p.  9]  This  subsystem  was  also  intended  to  include  the 
automation  of  the  Support  Action  Form  (SAF),  and  provide  various  reports  to 
management  to  assist  in  "managing  and  monitoring"  activities  in  the  OMA. 

4.  Configuration  Status  Accounting 

Configuration  accounting  refers  to  the  process  of  maintaining  a  record  of 
exactly  what  parts  are  in  and  what  changes  have  been  made  to  a  particular  item 
of  equipment.  Changes  or  modifications  to  aeronautical  equipment  are  directed 
by  what  are  called  technical  directives  (TD)  issued  by  NAVAIR.  When  changing 
components,  knowing  the  particular  configuration  is  critical  to  the  successful  re¬ 
pair.  This  subsystem  was  intended  to  automate  the  process  of  keeping  config¬ 
uration  records  for  all  aeronautical  equipment. 

5.  Personnel  Management 

Knowing  who  is  assigned  to  an  activity,  their  qualifications,  and  the  billet 
they  occupy  is  essential  to  ensuring  the  right  person  is  tasked  to  perform  a  par¬ 
ticular  job.  This  subsystem  was  intended  to  "collect  and  maintain  specific  per¬ 
sonnel  data  for  both  military  and  civilian  personnel  assigned  to  an  organization." 
[Ref.  46:  p.  9]  and  thereby  facilitate  assigning  the  right  person  to  each  task. 

6.  Asset  Management 

This  subsystem  was  essentially  an  inventory  system  for  all  aircraft  and 
equipment  assigned  to  an  activity.  Particular  attention  was  given  to  the  Individ¬ 
ual  Material  Readiness  List  (IMRL)  and  the  Aircraft  Maintenance  Material 
Readiness  (AMMRL)  Program.  Today,  the  Support  Equipment  Resources 
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Management  Information  System  (SERMIS)*7  is  performing  some  of  this  func¬ 
tion. 

7.  Local/Upline  Reporting 

This  subsystem  was  to  serve  as  the  interface  between  other  systems  and 
NALCOMIS/OMA.  It  was  to  collect  and  accumulate  information  and  then 
provide  summarized  reports  to  local  management.  In  addition,  higher  authority 
reporting  requirements  of  the  NAMP  would  be  satisfied  by  this  subsystem.  [Ref. 
46:  p.  10] 

8.  System  Support 

"Communication  between  organizations. ..through  the  maintenance  of  on¬ 
line  messages."  [Ref.  46:  p.  10]  was  to  be  handled  by  this  subsystem.  This  is  what 
is  now  called  electronic  mail  (E-mail).  This  service  would  have  been  provided  to 
all  organizations  linked  to  NALCOMIS. 

9.  Data  Offload/Onload 

This  subsystem  was  to  provide  the  means  to  extract  enter  data  about 
aeronautical  equipment  that  was  being  transferred  or  received.  An  OMA  has  no 
need  to  maintain  the  maintenance  history  for  an  aircraft  no  longer  in  its  custody. 
Similarly,  the  history  of  an  aircraft  newly  assigned  to  the  OMA  needs  to  be  added 
to  that  unit's  data  base.  Rather  than  enter  it  by  hand,  this  system  allowed  the 
data  to  be  entered  electronically. 

1 7  As  the  reader  will  recall  from  “Ill.  INFORMAL  ION  SYSTEMS"  on  pace  17  Si  R MIS 
is  a  system  to  aid  in  managing  support  equipment  at  all  aviation  activities  in  the  Navy. 
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10.  Technical  Publications 


The  technical  publications  necessary  to  maintain  modern  aircraft  are  vo¬ 
luminous.  Maintaining  an  inventory  of  ail  of  them,  and  where  they  actually  are 
located  is  a  job  to  which  many  people  have  been  dedicated.  This  subsystem  was 
intended  to  automate  that  herculean  task. 

1 1 .  Summary 

NALCOM1S  was  an  attempt  to  develop  an  information  system,  all  at  one 
time,  as  one  overall  project,  to  perform  all  of  these  functions.  Trying  to  do  it  all 
at  one  time  was,  and  still  is  too  ambitious  an  undertaking.  The  details  of  just  one 
function,  flight  hour  accounting,  are  enough  to  keep  several  people  busy  ad 
infinitum  with  configuration  management  after  deployment,  not  to  mention  the 
implementation  itself.  To  realize  the  complexity  of  the  procedures  we  are  trying 
to  automate,  consider  that  Volume  V  of  the  NAMP  [Ref.  45]  is  a  document  of 
over  700  pages  that  describes  how  the  Maintenance  Data  System  (MDS)  works. 
More  significantly,  it  specifies  in  laborious  detail  how  to  fill  in  the  v  arious  forms 
used  as  source  documents  for  the  MDS. 

We  should  learn  from  difficulties  associated  with  the  NALCOMIS  effort 
and  not  try  to  accomplish  too  much  all  at  once.  "The  only  unforgivable  failure  is 
[lie  failure  to  learn  from  past  failure."  [Ref.  4:  p.  6]  Any  project  for  OMAs  (in¬ 
cluding  OASIS)  should  cither  be  kept  small,  or  div  ided  into  smaller  projects  and 
implemented  one  at  a  time. 

C  OASIS  MODULE  DESCRIPTIONS 

The  modules  proposed  for  OASIS  are  similar  to  those  once  proposed  for  the 
now  defunct  NALCOMIS  OMA  (at  least  defunct  as  originally  envisioned  [Ref. 
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51]),  but  arc  organized  to  be  more  consistent  with  an  OMA's  primary  goal:  opti¬ 
mum  management  of  human,  monetary  and  material  resources.  They  are  pre¬ 
sented  hierarchically  in  Figure  5  on  page  67. 

Without  people  to  operate  and  maintain  them,  aircraft  will  not  fly,  therefore 
those  modules  dealing  with  human  resources  arc  addressed  First.  In  view  of  cur¬ 
rent  events  in  the  world,  and  the  much  discussed  "peace  dividend",  the  second 
priority  is  monetary;  thus  those  modules  are  described  next.  Third,  the  modules 
that  are  probably  the  most  difficult  to  develop,  those  that  address  the  manage¬ 
ment  of  material,  from  aircraft  to  piece  parts,  are  described.  Fourth  will  be  a 
brief  description  of  the  utility  functions  that  may  be  needed. 

1.  Human  Resources 

The  first  area  to  be  addressed  is  human  resources.  This  is  comprised  of 
two  modules.  First  is  the  Personnel  Management  Module  that  focuses  on  the 
information  needed  to  obtain  necessary  people,  and  how  to  assign  them  once  they 
have  arrived.  Second  is  the  Training  and  Qualifications  Module  that  focuses  on 
all  the  records  necessary  for  the  Assistant  Maintenance  Officer  to  effectively 
manage  the  personnel  assigned  and  their  training  and  qualifications. 
a.  Personnel  Management  Module 
An  OMA  requires  a  variety  of  people  of  various  rates  (work  spe¬ 
cialty),  paygradcs  (seniority),  and  training  (skill).  The  "ideal"  mix  of  people  is 
specified  in  the  Squadron  Manning  Document  (SQMD),  which  is  developed  early 
in  the  procurement  of  the  aircraft  weapon  system  from  the  Planned  Operating 
Environment  (POE)  statement  for  each  activity.  The  Naval  Military  Personnel 
Command  (NMPC)  assigns  real  people  to  each  activity  to  fill  the  billets'  speci- 
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Figure  5.  OASIS  Hierarchy  of  Modules 


fied  in  the  SQMD.  Those  assignments  are  made  according  to  priorities  that 
change  as  supply,  demand,  and  operational  commitments  change.  In  a  perfect 
system  e\ery  activity  would  have  all  the  people  specified  in  its  SQMD.  That 
however  is  seldom  the  case.  Usually  having  just  the  "right"  mix  of  talent  and  the 
right  number  of  people  requires  close  liaison  between  the  personnel  officer  (in 


reality,  usually  the  personnel  chief)  of  »he  activity,  the  Assistant  Maintenance 
Officer  (AMO)  of  the  activity,  the  next  higher  personnel  office  (usually  the  func¬ 
tional  wing),  and  NMPC.  It  involves  negotiation,  detailed  knowledge  of  the  as¬ 
signment  system,  and  most  importantly,  extensive  knowledge  of  the  real  skills  of 
the  people  in  the  OMA,  how  long  they  will  be  in  the  OMA,  and  what  the  future 
commitments  of  the  OMA  really  are.  The  entire  range  of  knowledge  required  by 
the  AMO  is  not  gained  overnight.  To  be  effective  in  obtaining  the  people  an 
OMA  needs  from  the  personnel  distribution  and  assignment  system  requires 
years  of  working  in  the  system,  OR  someone  else  with  those  years  of  experience, 
i.e.,  an  expert,  who  can  (and  will)  help  and  teach  you. 

Once  the  people  have  been  obtained  from  the  personnel  system  and 
have  actually  arrived  at  the  OMA,  there  is  the  problem  of  managing  specific  billet 
assignments  both  within  the  OMA  and  to  various  detachments.  The  initial  as¬ 
signment  is  usually  based  on  the  billet  to  which  the  individual  was  ordered,  the 
individual's  past  training  and  qualifications,  and  the  immediate  needs  of  the 
OMA.  Subsequent  assignments  are  based  on  what  the  managers  have  learned 
about  that  individual's  real  skills,  and  the  specific  needs  of  that  OMA. 

This  module  is  an  area  where  both  a  decision  support  system  and  an 
expert  system  could  be  beneficial.  The  internal  assignment  problem  is  fairly 
straightforward  and  may  lend  itself  to  a  DSS  solution  based  on  a  set  of  models 
with  constraints  included.  The  problem  of  obtaining  personnel  in  the  first  place 
may  be  best  solved  using  expert  system  techniques.  The  rules  of  the  personnel 
assignment  system  now  contained  in  assorted  instructions  could  be  encoded  in  a 
knowledge  base;  the  specifics  of  the  activity's  personnel  assignments  would  be 


contained  in  a  data  base;  and  the  knowledge  contained  in  the  minds  of  the  experts 
now  in  the  fleet  could  be  extracted  by  a  knowledge  engineer  and  encoded  in  the 
knowledge  base  as  well.18  Assigning  people  once  they  have  arrived  does  not 
necessarily  require  an  expert  system,  but  in  the  process  of  getting  them  there  in 
the  first  place  an  AMO  with  little  knowledge  of  the  Navy  personnel  system  could 
benefit  from  expertise  leveraged  in  the  form  of  an  expert  system.  The  analogy 
between  maintenance  managers  and  information  systems  applies  again.  Mainte¬ 
nance  officers  are  not  personnel  system  experts.  Yet  they  are  tasked  with  using 
that  system  to  achieve  the  goals  of  the  OMA.  Providing  them  "expertise"  in  the 
form  of  an  expert  system  could  significantly  reduce  the  time  they  must  spend 
learning  the  personnel  system  before  they  are  able  to  use  it  effectively  to  the  ad¬ 
vantage  of  their  OMA. 

b.  Training  and  Qualifications  Module 
Within  an  OMA.  two  of  the  Assistant  Maintenance  Officer  responsi¬ 
bilities  arc  to  "Establish  and  coordinate  the  department  training  program"  and 
"Obtain  school  quotas  to  support  training  requirements."  [Ref.  10:  p.  4-10]  As 
with  the  technology  associated  with  information  systems,  aircraft  technology  has 
also  made  great  advances.  Maintaining  aircraft  is  impossible  unless  people  have 
the  appropriate  skills.  Sources  of  those  skills  include  Navy  training  schools,  gen¬ 
eral  maintenance  training,  in-service  training,  aviation  maintenance  management 
teams,  and  manufacturer's  technical  representatives.  Means  of  measuring  train¬ 
ing  range  from  individual  testing  such  as  in  the  Maintenance  Training  Improvc- 

The  data  base  for  matching  an  activity's  Manpower  Authorization  (Ml’Ai  to  the  actual 
personnel  assigned  is  currcnth  being  designed  as  a  thesis  project  at  Naval  Postgraduate  School  |Rcf. 
52|. 
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ment  Program  (MTIP),  through  summaries  of  training  accomplished,  to  the  final 
measure,  sustained  aircraft  readiness.  Closely  coupled  to  training  is  the  need  to 
track  various  qualifications.  Examples  include  swim  qualifications,  specific  safety 
training,  welding  certifications,  and  other  one-time  or  periodic  qualification  type 
requirements.  The  paperwork  documentation  required  to  manage  the  training 
effort  is  tremendous.  For  example,  this  author,  in  one  month  has  had  to  per¬ 
sonally  review  a  10-20  page  report  on  each  of  nearly  150  people  in  his  depart¬ 
ment.  All  of  that  information  is  already  in  electronic  form;  in  fact  the  reports 
were  printouts  from  the  Aviation  Training  Support  System-Phase  11  (ATSS-11) 
system.  Therefore,  the  training  module  of  OASIS  should  provide  a  transparent 
interface  to  training  records  that  are  already  kept  electronically  in  ATSS. 

A  micro  computer-based  system  to  manage  and  track  the  training  re¬ 
quirements  listed  above  was  under  development  at  NAS  Miramar  in  1987-19S8. 
When  the  author  left  Fighter  Squadron  Twenty-One  (VF-21)  in  1988.  this  system 
was  in  use  at  VF-21,  VF-154,  and  AIMD  Miramar.  It  or  a  similar  system  could 
be  used  as  the  basis  for  the  module  to  help  AMOs  manage  training. 

2.  Monetary  Management 

The  second  area  to  be  addressed  is  monetary  management.  This  is  com¬ 
prised  of  two  modules.  First  is  the  OPTAR  Record-keeping  Module  that  focuses 
on  the  information  needed  to  manage  the  funds  OMAs  are  authorized  to  obligate. 
Second  is  the  Requisition  Records  Module  that  focuses  on  the  records  necessary 
to  keep  track  of  all  the  items  ordered  and  received  by  the  OMA. 
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a.  OPTAR  Record-keeping  Module 
OMAs  are  required  to  keep  a  record  of  all  funds  they  have  been  au¬ 
thorized  to  obligate  and  of  those  obligations.  These  records  are  usually  kept 
manually  in  the  OPTAR  log  (NAVCOMPT  2155).  The  specific  detailed  in¬ 
struction  for  correctly  maintaining  the  OPTAR  log  are  found  in  Navy  Staff  Of¬ 
fice  (NAVSO)  Publications  3006  and  3013  [Ref.  10:  p.  6-136].  If  those 
requirements  were  automated  then  much  of  the  time  spent  finding  and  correcting 
errors,  usually  simple  arithmetic  errors,  and  balancing  the  OMA's  records  with 
those  of  the  "official"  records  of  the  Fleet  Accounting  and  Disbursing  Center 
(FAADC)  could  be  reduced.  Processing  the  transmittals  (NAVCOMPT  2156), 
Summary  Filled  Order  Expenditure  Difference  Listings  (SFO  EDLs).  and 
monthly  Budget  OPTAR  Reports  (BOR)  could  be  streamlined  and  made  more 
accurate  by  automating  the  necessary  procedures.  Once  the  data  is  in  electronic 
form,  additional  potential  benefits  include  correcting  errors  at  the  point  of  entry, 
automatic  upline  reporting,  and  the  ability  to  present  the  data  in  a  variety  of 
formats,  even  pictures,  i.e.,  graphs,  for  upper  level  management  (usually  not  ex¬ 
perts  in  the  subject).  At  least  two  activ  ities  the  author  is  familiar  with  are  using 
a  simple  spreadsheet  package  to  accomplish  this  now.  The  problem  with  their 
applications  is  that  they  were  developed  by  people  who  have  since  left  the  activ¬ 
ity.  Now,  when  problems  occur  (and  they  will),  or  changes  are  required  (and  they 
will  be),  these  activ  ities  will  either  revert  to  the  manual  way  of  record-keeping  or 
will  find  someone  who  can  spend  the  time  learning  the  application  and  correcting 
the  problem  or  making  the  change. 
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b.  Requisition  Records  Module 

NALCOMIS  Phase  II  includes  a  terminal  for  most  OMAs  that  link:, 
them  to  their  local  supply  activity.  This  has  proven  of  great  value  to  maintenance 
managers.  It  is  used  to  order  parts,  to  inquire  about  status  of  previously  ordered 
parts,  and  to  verify  in  or  out  of  stock  situations.  Stock  information  is  critical  to 
a  maintainer.  If  the  part  is  essential,  one  of  the  alternatives  for  obtaining  the  part 
(if  it  is  not  available  from  supply)  is  to  take  it  out  of  an  otherwise  not  flyable 
aircraft.  "Cannibalizing,"  as  this  process  is  called,  requires  double  the  normal 
maintenance  effort.  Instead  of  removing  and  installing  one  component,  two  are 
removed  and  installed.  Three  components  are  now  exposed  to  potential  damage 
from  the  removal  and  installation  process,  rather  than  the  two  had 
cannibalization  not  been  necessary.  By  knowing  the  component  is  "on-the-shelf" 
and  "ready-for-issue"  (RFI),  a  maintenance  manager  can  minimize  unnecessary 
cannibalization  actions.  OASIS,  either  through  NALCOMIS  Phase  II  or  other 
means,  will  provide  a  means  of  obtaining  this  information. 

An  additional  benefit  of  obtaining  such  parts  information  is  the  pos¬ 
sibility  of  maintaining  an  automated  .equisition  logbook.  As  part  of  the  ordering 
process,  where  component  information  is  already  available  electronically  (through 
NALCOMIS  Phase  II),  capturing  that  information  and  loading  it  into  a  local 
OMA  data  base  would  be  of  great  benefit.  Part  numbers,  stock  numbers,  item 
description,  and  time  ordered  are  the  type  of  data  that  would  no  longer  have  to 
be  re-entered  every  time  an  item  is  ordered.  The  hand-scribed  (and  sometimes 
illegible)  logbook  now  required  could  be  replaced  by  a  clearly  readable  and  un¬ 
forgetting  automatic  one. 
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3.  Material  Management 

The  third  area  to  be  addressed  is  material  management.  This  is  com¬ 
prised  of  four  modules.  First  is  the  Flight  Activity  Module  that  focuses  on  re¬ 
cording  and  using  information  about  flights.  Second  is  the  Maintenance  Activ  ity 
Module  that  does  the  same  for  maintenance  actions.  Third  is  the  Maintenance 
Scheduling  Module  that  addresses  determining  the  optimum  schedule  for  com¬ 
pleting  repairs.  Fourth  is  Asset  Management  Module  that  addresses  the  inven¬ 
tory  management  of  OMA  assets. 

a.  Flight  Activity  Module 

This  module  collects  the  raw  data,  specifically  flight  hours,  used  to 
maintain  the  logbooks  of  aeronautical  equipment.  One  of  the  functions  of  this 
module  of  OASIS  will  be  to  prov  ide  an  automated  logbook.  Current  procedures 
require  many  calculations  to  properly  remove  and  install  equipment  in  an  air¬ 
craft.  and  once  installed,  to  account  for  the  operating  time  of  that  equipment. 
By  automating  those  procedures,  many  of  the  hours  this  author  has  witnessed 
(and  spent)  finding  simple  arithmetic  errors  can  be  avoided.  Additionally,  since 
the  data  is  kept  electronically,  the  only  time  a  paper  copy  would  be  needed  would 
be  when  the  equipment  is  transferred,  or  when  signatures  tire  required.  That 
paper  copy  could,  at  least  for  now.  be  an  exact  replica  of  the  logbook  forms  cur¬ 
rently  used.  This  could  change  in  the  future  should  the  need  for  the  paper  form 
be  removed.  This  module  would  be  used  to  provide  MCCs  with  up-to-the  min¬ 
ute  status  of  any  of  the  aircraft  under  their  care. 

Might  hours  accrued  by  a  component  are  one  of  the  ways  of  deter¬ 
mining  when  to  perform  scheduled  maintenance  of  aeronautical  equipment. 


Collecting  that  information  as  it  occurs  has  a  significant  impact  on  even  simple 
maintenance  actions  like  an  oil  sample  that  may  be  due  every  ten  hours  of  oper¬ 
ation.  Most  OMAs  have  devised  some  way  of  keeping  the  MCCs  aware  of  which 
components  are  coming  due  for  a  particular  preventative  maintenance  action. 
The  terms  "Time  since  new  sheet",  and  "Time  sheet"  are  used  to  describe  these 
end-user  developed  information  systems.  Some  are  automated,  and  some  are  still 
manual.  All  provide  MCCs  with  a  single  sheet  containing  the  time  remaining 
until  the  next  required  preventive  maintenance  action19. 

Configuration  accounting  is  one  of  the  functions  of  aeronautical 
equipment  logbooks.  Accordingly  that  function  should  be  performed  by  the 
module  that  contains  the  automatic  logbook.  The  data  necessary  to  maintain  an 
accurate  configuration  for  all  equipment  will  come  from  the  VI DS  MAF  data 
representing  technical  directive  compliance  when  that  data  is  collected  in  the 
Maintenance  Activity  Module  (discussed  in  “b.  Maintenance  Activity  Module" 
on  page  75).  As  parts  arc  removed  and  replaced  on  aircraft  or  other  aeronautical 
equipment,  the  data  entered  to  record  those  actions  would  automatically  update 
the  configuration  records  for  the  equipment. 

The  computer  aided  NAVFL1R  data  entry  system  (CANDES)  is  a 
micro  computer-based  system  that  performs  the  flight  data  collection  function, 
but  with  the  intention  of  providing  the  NAVFL1R  data  into  an  elect' onic  form 


19  Some  of  these  sheets  present  the  information  on  an  accruing  tune  basis.  What  is  printed 
is  the  amount  of  time  since  the  previous  maintenance  action  occurred.  1  his  means  that  the  MC( 
must  perforin  some  arithmetic  to  arrive  at  the  "due"  time  of  the  next  action.  Another  type  counts 
down  to  zero  The  times  listed  on  the  time  sheet  are  the  amount  ot  time  remaining  until  Un¬ 
specified  action  must  be  performed.  Most  of  these  reports  are  produced  once  a  day.  and  the  NIC  ( 
performs  simple  arithmetic  through  the  day  to  update  the  figures  on  his  sheet 
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to  Data  Services  Facilities  (DSFs)  to  upload  into  the  AV-3M  system.  CANDES 
was  born  in  the  spring  of  1989  and  first  tested  in  November  1989  [Refs.  53  and 
54].  At  last  report  [Ref.  54],  it  is  a  success  at  all  sites  where  it  has  been  fielded, 
and  plans  to  install  it  at  additional  sites20  are  being  implemented.  CANDES 
could  be  expanded  to  fulfill  other  flight  hour  related  or  dependent  functions  and 
become  the  Flight  Activity  Module  of  OASIS. 
b.  Maintenance  Activity  Module 

The  maintenance  history  of  aircraft,  both  an  individual  aircraft,  and 
an  entire  type,  model,  series  (TMS)  of  aircraft,  can  be  very  valuable  to  main- 
tainers.  If  there  is  a  sufficient  history  of  equipment  failure,  then  future  failures 
can  be  predicted  with  a  specified  lev  el  of  confidence.  If  MCCs  had  access  to  such 
data  they  could  make  better  educated  decisions  about  the  likelihood  of  a  partic¬ 
ular  part  being  the  cause  of  the  current  problem  facing  them.  Another  use  of 
historical  data  is  planning  which  parts  and  how  many  of  each  to  take  on  a 
detachment.  If  two  widgets  fail  every  week,  and  the  detachment  is  one  week, 
then  taking  two  widgets  would  be  appropriate.  The  same  parts  usage  data  is  used 
by  procurement  activities  to  decide  how  many  of  each  part  to  buy  for  a  gi\en 
period  of  time.  The  means  to  obtain  historical  data  must  be  part  of  this  module. 
Current  data  must  be  collected  as  it  is  generated  by  current  maintenance  actions. 
Additionally,  historical  d  '*a  may  be  available  from  the  AV-3M  or  NALDA  sys- 

20  At  this  writing.  which  Navy  activity  will  he  the  configuration  manager  and  who  will  provide 
post  deployment  systems  support  lor  (  AN I'M  S  has  not  been  decided  I  his  means  that  when  (and 
ill  CANDIS  transitions  from  the  Naval  Aviation  Maintenance  Support  Office  iNAMSO)  proto¬ 
type  to  an  implemented  system,  there  may  he  no  support 
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terns.  A  user-transparent  retrieval  of  historical  data  from  those  systems  is  essen¬ 
tial. 

Collection  of  data  about  maintenance  actions  as  they  occur  must  be 
a  priority.  Each  aircraft  has  its  own  "personality",  or  failure  tendencies,  and 
quick  access  to  data  about  an  aircraft's  past  failures  can  sometimes  give  indi¬ 
cations  about  current  problems.  Additionally,  monitoring  trends,  now  done 
laboriously  by  quality  assurance  personnel  reviewing  individual  VIDS  MAFs, 
could  be  automated.  Some  pre-defined  trends  could  be  tracked  on  a  regular  ba¬ 
sis,  such  as  how  many  reported  failures  could  not  be  duplicated  during  trouble¬ 
shooting.  Other  trends  could  be  provided  on  an  ad  hoc  basis. 

Once  the  data  is  in  electronic  form,  it  can  also  be  used  to  satisfy  up¬ 
line  reporting  requirements.  Readiness  statistics  in  the  form  of  mission  capable 
and  full  mission  capable  figures  could  be  calculated  automatically  in  accordance 
with  both  the  NAMP  and  AV-3M  system  which  monitors  the  full  twenty-four 
hour  per  day  capability,  and  the  Aircraft  Material  Readiness  Report  (AMRR) 
which  provides  a  "snapshot"  of  aircraft  status  (typically  at  the  start  of  daily  flight 
operations). 

One  of  the  forms  used  to  collect  data  is  the  VIDS  MAF.  It  contains 
over  50  blocks  of  different  data  elements,  with  over  200  spaces  for  data.  The 
VIDS  MAF  has  been  limited  to  one  page  for  years  in  an  effort  to  minimize  the 
paperwork  as  well  as  to  not  overwhelm  those  who  must  fill  in  the  forms.  To  that 
end.  associated  with  each  block  is  a  set  of  codes  used  to  describe  the  maintenance 
action  that  occurred  [Ref.  45:  p.  6-1 1],  If  we  go  to  a  computerized  version  of  data 
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collection,  the  arguments  for  one  page  become  less  compelling21.  The  ease  with 
which  windowing22  is  used  in  today's  technology  would  allow  the  presentation  to 
the  user  of  only  that  information  required  at  that  particular  stage  in  the  mainte¬ 
nance  action  documentation  process.  The  necessary  codes  could  be  displayed  on 
demand.  Another  option  would  let  the  user  pick  the  correct  code  from  a  list  on 
the  video  terminal  screen,  thereby  eliminating  most  of  the  guessing,  typing,  and 
tianscription  errors.  A  computerized  version  of  the  VIDS  MAF  would  also  allow 
more  descriptive  information  in  the  write  up  of  the  actual  problem.  The  point  is 
that  even  though  more  complete  and  accurate  data  could  be  collected,  each  user 
would  have  to  deal  only  with  that  portion  of  the  data  that  applied  to  him  her. 

We  may  not  be  able  to  do  away  with  paper  entirely,  since  there  will 
remain  the  need  for  signatures  at  some  points  of  the  maintenance  cycle.  That 
signature  requirement  could  be  satisfied  if  we  had  the  data  collection  system  print 
the  signature  part  of  the  VIDS  MAF  whenever  someone  must  actually  affix 
his  her  signature.  There  may  be  other  alternatives  to  signatures,  and  these  need 
to  be  considered  and  evaluated.  If  weaning  maintainers  from  their  VIDS  board 
proves  too  difficult2?,  then  have  OASIS  print  a  form  (which  could  be  adapted  to 
the  preferences  of  the  specific  OMA)  for  the  VIDS  board— just  do  the  data  entry 
at  a  terminal  and  get  the  data  at  the  source.  Benefits  of  automation  include  more 

21  This  docs  not  imply  that  we  should  collect  more  data,  only  that  we  can  now  use  a  single 
screen  display  for  each  step  m  the  maintenance  process,  and  that  the  one  page  limit  should  be  re¬ 
evaluated  in  light  of  using  computen/ed  data  entry  versus  a  paper  form. 

22  "Windowing"  refers  to  the  ability  to  overlay  a  second  (or  more)  screen  of  information,  even 
including  the  running  of  another  application,  on  top  of  the  one  currently  in  use. 

23  After  an  unbiased  comparative  analysis  of  both  the  VID  system  and  the  computer  based 
system,  we  may  find  that  the  VIDS  has  advantages  wc  are  unwilling  to  give  up  Two  such  advan¬ 
tages  are  that  it  is  not  subject  to  electrical  power  failures  and  that  it  is  alreads  well  known  and  un¬ 
derstood  throughout  the  fleet. 


accurate  data:  maintainers  won't  be  "remembering"  which  code  to  use  in  which 
block,  but  will  be  able  to  pick  the  right  one  from  a  list  in  front  of  them.  No  more 
legibility  problems  at  the  DSF,  no  more  typographical  problems,  at  least  within 
the  allowable  characters  for  a  given  block,  and  fewer  keypunch  errors  are  all 
likely  results  of  collecting  data  in  electronic  form. 

c.  Maintenance  Scheduling  Module 

An  expert  system  to  assist  Maintenance  Control  Chiefs  in  allocating 
their  scarce  resources  optimally  among  all  the  competing  short,  medium,  and  long 
term  objectives  would  be  the  key  element  of  this  module.  Such  an  expert  system 
was  found  to  be  feasible  by  McCaffrey  in  1985  [Ref.  6:  p.  122].  As  previously 
discussed,  the  supply  of  true  experts  in  the  field  of  maintenance  is  below  the  de¬ 
mand.  so  the  need  to  leverage  those  we  do  have  is  great.  Even  though  expert 
systems  have  reached  the  commercial  market  since  McCaffrey's  work  in  1985. 
their  use  by  DOD  the  operating  activities  is  low  or  non-existent.  Therefore,  a 
particularly  productive  project  for  the  Navy's  graduate  students  at  the  Navy 
Postgraduate  School  would  be  to  apply  ES  techniques  to  helping  all  maintenance 
chiefs  be  more  effective.  The  first  part  of  the  problem  to  be  addressed  should  be 
something  readily  definable,  such  as  some  of  the  scheduled  maintenance  require¬ 
ments.  Later  iterations  could  add  other  aspects,  un-scheduled  maintenance,  for 
example.  In  that  way,  OMAs  could  benefit  from  having  a  "consistent  expert 
available  at  any  time. 

d.  Asset  Management  Module 

Although  assigned  to  the  material  control  work  center  (except  for 
publications),  these  functions  cross  all  work  center,  division,  and  department 


7K 


boundaries  and  are  therefore  grouped  into  the  one  module.  In  effect  this  is  an 
automated  inventory  system  for  all  OMA  assets.  Keeping  track  of  all  an  OMA's 
assets  is  a  very  time-consuming  repetitive  task  that  requires  meticulous  attention 
to  detail  Such  tasks  are  ideally  suited  to  automated  record-keeping.  OMA  assets 
include  everything  from  janitorial  equipment  and  office  supplies  to  expensive  test 
equipment  and  computers.  The  technical  publications  library,  which  includes  all 
the  repair  manuals  as  well  as  Naval  instructions,  is  included  as  are  IMRL 
equipment  and  common  hand  tools. 

The  tool  control  program  requires  positive  accountability  of  all  tools 
lest  they  find  their  way  into  the  wrong  place  and  do  damage  (known  as  foreign 
object  damage  or  FOD).  To  achieve  such  accountability,  accurate  and  detailed 
inventory  records  of  every  tool  are  imperative.  The  tool  boxes  for  these  tools  are 
arranged  with  some  means  of  visually  ascertaining  in  just  a  few  seconds  that  ev¬ 
ery  tool  that  belongs  in  tha  container  is  there  or  that  its  location  is  known.  A 
future  enhancement  to  this  module,  as  technology  inexorably  adv  ances,  would  be 
to  add  the  shadow  diagrams  for  every  tool  box  to  the  automated  inventory  re¬ 
cords.  This  would  allow  the  tool  control  plan  for  each  aircraft  to  be  distributed 
electronically,  rather  than  on  paper. 

The  master  inventory  of  the  activity's  aircraft  would  also  be  kept  by 
this  module.  Flight  packets  would  be  accounted  for  and  even  "signed  for  by  pi¬ 
lots  through  this  module  as  they  signed  foi  their  aircraft.  When  the  technical 
publications  library  is  distributed  via  Compact  Disk-Read  Only  Memory 
(CD-ROM),  the  ease  with  which  MCCs  could  search  for  and  find  the  obscure 
detail  about  a  component,  procedure,  or  requirement  would  be  greatly  enhanced. 
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4.  System  Utilities  Module 

This  module  will  perform  a  number  of  diverse  functions  common  to  the 
other  modules.  The  list  is  not  exhaustive:  in  fact,  other  general  utility  functions 
will  undoubtedly  be  desired  by  the  end-users.  The  minimum  starting  set  of 
functions  is  described  in  the  following  sections. 

a.  Receipt  and  Transfer 

Receipt  and  transfer  of  equipment  would  be  a  function  of  this  mod¬ 
ule.  Any  time  an  item  was  received,  data  from  its  logbook  would  electronically 
be  added  to  the  OMA's  inventory  via  this  module.  Upon  transfer;  just  the  re¬ 
verse  would  occur.  Any  necessary  paper  copies  would  first  be  printed  and  then 
the  electronic  logbook  would  be  transferred,  either  directly  via  communications 
link  or  by  diskette.  This  process  would  apply  to  aircraft  in  particular  but  also  to 
all  other  aeronautical  equipment,  particularly  support  equipment  and  1MRL. 

b.  Communications 

A  telecommunication  system  would  connect  all  parts  of  the  system. 
The  interfaces  to  other  systems  would  be  transparent  to  the  user  because  of 
standard  interface  programs  contained  in  this  module.  Also  included  would  be 
an  electronic  mail  (E-Mail)  system.  This  would  operate  on  what  would  effectively 
be  a  local  area  network  (LAN)  within  the  OMA.  The  telecommunications  capa¬ 
bility  would  allow  readiness  reports,  for  example,  to  be  prepared  by  the  analyst, 
reviewed  by  the  Quality  Assurance  Officer,  the  Assistant  Maintenance  Officer 
(AMO),  the  Maintenance  Officer  (MO),  the  Operations  Officer  (OPSO).  the 
Executive  Officer  (XO),  and  the  Commanding  Officer  (CO)  and  then  to  be  sent 
to  higher  authority  without  ever  being  produced  on  paper. 
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c.  Database  Management  and  Maintenance 
All  database  management  and  maintenance  functions  would  be  per¬ 
formed  by  this  module  also.  Periodic  backup  of  the  OMAs  database  would  be 
automatic.  Any  batch  processing  such  as  periodic  standard  reports  would  be 
handled  within  this  module.  In  effect,  this  module  would  be  the  "traffic  cop"  for 
data  flow  within  OASIS.  The  precedence  procedures  to  prevent  two  people  from 
trying  to  change  the  same  data  element  at  exactly  the  same  time  would  be  en¬ 
coded  here.  The  database  management  system  must  include  the  capability  to 
support  a  wide  array  of  ad  hoc  queries.  A  minimum  requirement  is  including  the 
standard  query  language  (SQL). 

5.  Summary 

The  module  descriptions  presented  represent  the  conceptual  organization 
of  OASIS.  It  should  be  readily  apparent  that  developing  a  single  system  to  per¬ 
form  all  these  functions  is  a  demanding  task.  In  fact,  it  is  simply  too  big  and  too 
complex  to  accomplish  in  one  system  development  effort,  as  the  history  of 
NALCOMIS  shows.  A  project  of  this  size  will  take  too  long  and  will  make 
keeping  up  with  changes  even  more  difficult  during  development  because  the 
longer  the  development  time,  the  more  changes  are  likely  to  occur.  Such  an  ef¬ 
fort,  trying  to  develop  and  del i\ er  everything  all  at  one  time.  is.  howe'er  well- 
intentioned,  doomed  to  fail. 

D.  IMPLEMENTATION  PLAN 

This  section  will  address  some  general  systems  implementation  issues  as  they 
relate  specifically  to  OASIS,  anti  then  outline  the  preliminary  OASIS  implemen¬ 
tation  plan.  The  plan  is  only  preliminary,  since  it  w  ill  need  to  be  in  much  greater 
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detail  than  possible  here.  Additionally,  the  plan,  once  formalized  will  be  subject 
to  frequent  change.  Another  factor  is  that  information  systems  planning  has 
advanced  so  far  technologically  that  even  the  strategic  planning  process  is  now 
automated.  At  least  the  documenting  of  the  process  and  resulting  plans  is  auto¬ 
mated.  (We  haven't  automated  thinking  yet).  The  value  of  such  automated  tools 
is  significant  particularly  to  a  project  such  as  OASIS  which  is  intended  to  evolve 
and  change  as  each  module  is  added  and  as  the  operating  environment  changes. 
Automating  the  record-keeping,  documenting  and  plan  generating  will  both  ease 
the  administrative  burden  and  reduce  the  potential  for  overlooking  something 
when  making  changes  to  the  project  specifications  and  plans.  Those  who  actually 
develop  OASIS  should  take  advantage  of  the  automated  development  tools 
available  today. 

1.  Related  Issues 

There  are  several  issues  related  to  the  development  of  any  information 
system  for  aviation  maintenance.  They  include  identifying  the  customers  of  the 
system,  deciding  whether  to  develop  the  system  in-house  or  contract  for  the  de¬ 
velopment,  developing  a  data  dictionary  directory,  deciding  which  hardware  and 
software  to  use,  identifying  and  specifying  interface  requirements,  identifying 
potential  applications  for  expert  systems,  deciding  whether  to  follow  a  traditional 
or  prototyping  approach,  performing  a  cost-benefit  analysis  of  the  project,  and 
evaluating  previously  proposed  systems  for  inclusion  in  OASIS. 
a.  OASIS  Customers 

Many  people  in  aviation  maintenance  need  information  about  read¬ 
iness.  If  OASIS  is  to  satisfy  their  needs,  identifying  those  customers  explicitly  is 
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essential.  To  any  organization,  customers  fall  into  two  groups,  internal  and  ex¬ 
ternal.  Internally,  the  customers  of  OASIS  are  the  professional  maintenance 
managers  who  have  spent  years  learning  their  profession,  the  Maintenance  Con¬ 
trol  Chiefs,  and  professional  maintenance  officers.  Other  beneficiaries  include 
aviators  assigned  as  Maintenance  Officers  and  Division  Officers,  the  quality  as¬ 
surance  division,  and  material  control  and  maintenance  administration  work 
centers.  By  virtue  of  the  benefits  accrued  by  those  professional  maintenance 
managers,  the  whole  activity  will  benefit  from  better  overall  performance  and 
readiness.  None  of  these  users  will  really  care  what  the  system  is  called  or  how 
they  got  it.  as  long  as  it  helps  them  do  a  better  job. 

Externally,  the  customers  of  OASIS  are  all  the  other  systems  with 
which  it  must  interact  and  those  higher  authorities  to  which  the  OMA  provide 
both  raw  and  summarized  data.  Some  of  these  have  already  been  identified,  but 
an  exhaustive  list  should  be  prepared  that  includes  a  detailed  description  of  the 
technical  hardware  and  software  interface  requirements  for  each. 

b.  In-house  Development  versus  Out-house  Development 

The  question  as  to  whether  OASIS  should  be  developed  within  the 
Navy  or  outside  the  Navy  by  a  contractor,  must  be  thoroughly  analyzed  and 
finally  decided.  There  arc  benefits  to  both.  By  doing  the  development  in-house, 
we  have  control  of  the  entire  system  development,  do  not  have  to  learn  the  av  i¬ 
ation  maintenance  business,  and  do  not  have  to  worry  about  a  contractor  not 
going  to  sea  to  maintain  the  system  he  just  delivered.  On  the  other  hand,  we  must 
maintain  the  information  systems  expertise  to  develop,  implement,  and  support 
the  system  after  deployment.  In  this  era  of  fewer  funds,  doing  the  development 
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with  people  who  are  already  "on  staff"  avoids  the  cost  of  hiring  new  people. 
However,  those  same  "on  staff"  people  must  devote  time  to  system  development 
that  they  would  normally  devote  to  other  duties.  The  real  impact  and  cost  of 
both  options  needs  to  be  investigated.  One  of  the  things  strongly  favoring  in- 
house  development  is  the  growth  of  end-user  development. 

(1)  Managed  End-user  Development.  End-users  (the  internal 
customers)  have  little  or  no  idea  of  what  can  be  done  with  current  information 
systems.  They  are  aircraft  maintainers,  not  information  system  developers. 
What  is  needed  is  to  somehow  expose  them  to  the  possibilities.  The  best  way  to 
do  that  is  to  provide  them  something  they  can  use,  i.e.,  something  that  will  help 
them  do  their  jobs,  while  at  the  same  time  sparking  their  imagination  about  other 
functions  an  IS  can  help  them  accomplish  more  effectively.  Those  ideas  can  then 
be  incorporated  in  the  next  release  of  OASIS.  This  procedure  is  much  the  same 
as  followed  by  marketers  of  major  software  products,  and  is  also  part  of  the  phi¬ 
losophy  advocated  by  Total  Quality  Management,  i.e.,  continual  improvement. 

For  the  same  reason,  i.e.,  end-users  have  little  or  no  idea  of 
what  can  be  done  with  current  IS  technology,  to  expect  them  to  be  able  to  define 
their  requirements  at  the  very  beginning  of  a  project  in  a  manner  from  which  an 
IS  could  be  developed  is  expecting  too  much.  To  do  so  is  to  invite  the  chance  of 
missing  out  on  an  opportunity  to  take  advantage  of  1)  software  and  hardware 
technology  advances  that  occur  during  a  long  development,  and  2)  end-users' 
imaginations  that  can  be  stirred  by  having  a  sample,  i.e.,  a  prototype.  Therefore, 
an  effort  to  manage  the  end-users'  developed  applications  in  conjunction  with 
OASIS  prototypes  is  essential.  In  reality,  some  of  the  end-user's  applications  may 
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very  well  form  the  beginning  of  OASIS  modules,  if  not  becoming  the  modules 
themselves. 


(2)  N AMD's  Functions.  The  Naval  Aviation  Maintenance  Office 
(NAMO)  has  several  responsibilities  specified  in  the  NAMP.  Among  them  are 
"Developing  and  maintaining  management  information  systems  which  directly 
support  the  fleet, "  and  "Planning,  design,  development,  implementation,  and 
support  of  all  information  systems;decision  support  systems  which  support  the 
total  life  cycle  of  aeronautical  equipment."  [Ref.  9:  p.  4-4]  These  responsibilities 
are  effectively  a  charter  for  NAMO  to  bring  all  fleet  aviation  maintenance  and 
support  information  systems  under  NAMO's  purview. 

(a)  Central  Design  Activity—  In  accordance  with  its 
NAMP  charter.  NAMO  should  be  the  Central  Design  Activity  (CDA)  for  all 
aviation  maintenance  information  systems,  from  the  Naval  Aviation  Logistics 
Data  Analysis  system  (NALDAj  and  the  AV-3M  to  OASIS.  As  CDA.  NAMO 
would  have  the  unique  opportunity  of  being  the  keepers  of  both  the  NAMP  and 
the  information  systems  that  support  the  NAMP.  In  other  words,  the  mainte¬ 
nance  experts  who  manage  the  NAMP  would  have  the  same  chain  of  command 
as  the  information  professionals  who  provide  the  information  systems  for  the 
NAMP.  As  two  different  groups  of  professionals  with  the  same  goal.  i.e..  support 
to  the  fleet,  such  a  relationship  can  have  only  synergic  benefits.  The  parallel  to 
the  relationship  between  aviation  maintenance  and  aviation  supply  is  inescap¬ 
able.  The  maintenance  supply  relationship  resulted  in  the  Joint  Aviation  Supply 
Maintenance  Material  Management  school  being  developed.  It  is  time  for  a 
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similar  relationship  between  experts  in  maintenance  and  experts  in  information 
systems  to  be  established. 

(b)  Configuration  Management—  NAMO  can  and 
should,  under  the  authority  of  its  charter,  act  as  a  clearinghouse  and  configura¬ 
tion  manager  for  end-user  developed  applications.  Of  particular  interest  are 
those  that  are  not  (yet)  part  of  OASIS,  but  that  might  be  af  benefit  to  OMAs 
other  than  the  one  that  developed  the  application.  In  response  to  a  request  from 
NAMO,  an  OMA  would  send  NAMO  a  copy  of  their  application.  NAMO 
would  be  responsible  for  verifying  that  it  complied  with  the  NAMP  and  other 
applicable  instructions  and  standards.  NAMO  would  then  make  any  changes 
deemed  necessary,  e.g..  superimpose  a  standard  user  interface.  Finally.  NAMO 
would  make  a  compiled  version-4  available  to  all  other  OMAs  either  by  electronic 
bulletin  board,  or  by  mailing  diskettes.  The  original  developer  would  submit 
preliminary  support  (both  user  and  maintenance)  documentation  in  electronic 
form,  which  N^MO  would  update  as  it  updated  the  code  and  subsequently  pro¬ 
vide  to  ail  users  as  part  of  the  product.  This  whole  process  should  occur  elec¬ 
tronically.  Because  of  the  volume  and  variety  of  the  cna  nser  applications. 
NAMO  would  have  to  liltcr  the  responses.  In  other  words,  if  2c  applications  to 
automate  the  logbook  were  received,  NAMO  would  choose  or  combine  features 
from  different  applications  into  a  single  version  of  the  automated  logbook  which 
would  then  be  supported  by  NAMO.  (NAMO  may  not  provide  the  actual  post 
deployment  software  support,  but  would  coordinate,  as  the  configuration  man- 

24  A  compiled  version  is  one  that  has  been  reduced  to  actual  machine  instructions,  and  is  no 
longer  in  the  original  programming  language  (called  the  source  coder 
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ager,  the  PDSS  efforts.  The  actual  support  may  be  provided  by  Navy  software 
activities,  NPS,  or  contractors.)  The  availability  of  these  application  programs 
should  then  be  made  known  to  all  OMAs.  This  could  be  initially  done  via  Naval 
message,  with  subsequent  follow-up  articles  and  listings  in  professional  aviation 
maintenance  magazines  such  as  MECH  and  CROSSFEED.  Even  possible,  but 
unlikely  in  view  of  expected  funding  limits,  is  that  a  separate  publication  could 
be  started  to  advertise  the  applications  available  as  well  as  to  provide  articles  of 
general  interest  to  aviation  maintenance  computerized  information  systems  users. 
At  the  very  least,  an  electronic  bulletin  board  should  contain,  if  not  the  actual 
programs  and  documentation,  a  list  of  what  is  available  and  how  to  get  them. 

(3)  Participation.  NAMO  should  solicit  users'  input  as  to  the 
first  module  to  be  developed.  Those  who  should  be  consulted  include  the  OMAs 
(the  end-users),  Type  Commanders,  Fleet  Commanders,  the  Aviation  Mainte¬ 
nance  Officer  School,  and  the  current  NALCOMIS  office  (PMA-270).  Once  the 
first  module  has  been  selected,  developed  and  fielded,  the  next  one  should  be 
chosen  and  the  process  repeated.  As  each  module  is  developed  and  feedback  is 
received  from  the  end-users,  priorities  may  actually  change  from  those  proposed 
in  the  preliminary  implementation  plan.  If  that  is  the  case.  fine.  There  is  nothing 
sacred  about  the  preliminary  implementation  plan  for  OASIS. 
c.  Data  Dictionary  I  Directory  System 
A  simple  but  potentially  very  time-consuming  issue  is  that  of  the  spe¬ 
cific  data  elements  an  activity  (and  OASIS)  will  use.  For  example,  a  decision  is 
necessary  as  to  whether  a  social  security  number  is  nine  digits  separated  by  hy¬ 
phens.  nine  consecutive  digits,  or  some  other  arrangement  of  digits  and  symbols. 
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Another  example  is  the  format  for  a  date.  There  are  dozens  of  variations,  from 
day  month  year,  to  a  four  or  five  digit  Julian  date.  The  MDS  Validation  Spec¬ 
ifications  [Ref.  55],  also  known  as  the  VALSPECS  should  be  used  to  establish  the 
initial  data  dictionary.  As  applications  are  developed,  a  data  directory  should 
be  added  so  that  the  impact  of  changes  proposed  in  the  future  could  be  assessed, 
as  well  as  ensuring  that  those  changes  actually  made  are  complete.  Once  the  in¬ 
itial  DD/DS  is  established  from  the  VALSPECS,  the  systems  with  which  OASIS 
must  interact  should  be  assessed  to  1)  determine  what  if  any  differences  exist,  and 
2)  build  standard  conversion  modules  to  make  data  transfer  among  them  trans¬ 
parent  to  the  end-users. 

d.  The  Hardware-Software  Decision 
Deciding  which  specific  software  and  hardware  OASIS  will  use 
should  be  left  until  as  late  as  possible  in  the  development  cycle.  Initially,  for  the 
prototypes,  existing  hardware  and  software  could  be  made  to  suffice.  Only  when 
OASIS  approaches  full  functionality  should  the  decision  about  hardware  and 
software  be  finalized.  That  way,  the  latest  advances  in  both  technologies  can  be 
made  a  part  of  OASIS.  Of  course,  since  the  micro  computers  of  today  have  the 
capability  of  mainframes  and  mini  computers  of  15  years  ago.  assuming  that 
OASIS  will  be  based  on  a  micro  computer  is  a  safe  and  logical  assumption.  The 
specific  make,  model  and  capabilities  should  be  left  until  a  better  understanding 
of  the  functional  and  technical  requirements  is  obtained  through  the  development 
of  the  first  few  modules.  This  of  course  implies  that  the  first  few  modules  will 
be  required  to  work  on  the  hardware  and  software  already  available  at  most 
OMAs. 
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The  question  of  which  software  package  or  combination  of  packages 
to  use  to  develop  OASIS  must  also  be  answered.  This  issue  will  have  to  include 
a  decision  as  whether  or  not  to  standardize  on  one  language  (such  as  ADA)  for 
all  of  OASIS  development.  Many  application  packages  are  available,  from  basic 
spreadsheet  and  database  packages  to  more  advanced  and  sophisticated  fourth 
generation  languages.  These  packages  were  designed  to  perform  the  same  type 
of  functions  needed  in  some  OASIS  modules.  Using  them  may  reap  the  benefit 
of  easy  development,  but  may  also  incur  the  threat  of  poor  or  no  support  at  some 
time  in  the  future.  ADA  on  the  other  hand,  is  the  DOD  directed  standard  lan¬ 
guage  and  therefore  we  have  some  assurance  of  long  term  support.  However, 
using  ADA  would  involve  considerably  more  effort  than  using  commercially 
available  software  application  packages.  It  would  also  mean  that  all  the  appli¬ 
cations  already  developed  and  in  use  would  have  to  be  re-written.  Whatever  de¬ 
cision  is  made  will  have  long  term  implication;-  for  both  development  and  post 
deployment  support  and  maintenance  of  the  system.  This  decision  should  not  be 
made  lightly,  and  in  fact  may  require  a  study  of  its  own. 
c.  Interface  Requirements 

The  need  for  OASIS  to  interact  with  other  information  systems  must 
be  recognized  from  the  outset.  NALCOMIS  Phase  II.  SUADPS.  UADPS  and 
NALDA  arc  four  of  those  for  which  an  interface  must  be  developed.  Since  they 
most  likely  have  different  technical  and  logical  requirements  for  interaction,  each 
of  them  must  be  investigated  and  the  interface  requirements  specified.  This  will 
involve  such  things  as  the  format  and  order  of  specific  data  elements,  as  well  as 
the  technical  specifications  such  as  transfer  rate.  Once  those  requirements  are 
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known,  standard  modules  should  be  developed  to  be  included  with  OASIS  mod¬ 
ules  sent  to  an  OMA  that  must  interact  with  any  of  those  systems.  For  example, 
to  link  to  NALCOMIS  Phase  II  will  require  that  the  data  conform  to  the 
VALSPECS,  but  also  data  transfer  protocol  must  be  specified.  These  are  tech¬ 
nical  details  beyond  the  scope  of  this  thesis,  but  they  must  be  resolved  for  OASIS 
to  reach  its  full  usefulness  to  OMAs. 

/.  Expert  Systems 

All  the  fault  isolation  in  the  world  will  not  fix  the  fault.  Once  a  piece 
of  equipment  has  failed,  and  the  fault  has  been  isolated,  the  real  problem  of  al¬ 
locating  resources  to  repair  it  begins.  Resource  allocation  necessitates  consider¬ 
ation  of  the  OMA's  goals  and  missions.  Short  term  goals  like  today's  flight 
schedule,  medium  term  goals  like  next  month's  detachment  to  NAS  Wherever, 
and  long  term  goals  such  as  the  next  deployment  should  all  have  an  impact  on 
the  allocation  of  resources. 

Expert  systems  hold  significant  potential  to  assist  in  several  areas  of 
aviation  maintenance  and  particularly  that  of  resource  allocation.  Resource  al¬ 
location  is  essentially  what  MCCs  do.  They  consider  the  resources  available  to 
them,  e.g.,  time,  people,  funds,  equipment  and  tools,  compare  those  resources  to 
their  goals,  and  formulate  a  plan  to  achieve  those  goals.  Leveraging  the  expertise 
of  the  most  experienced  maintenance  chiefs  for  each  type  of  aircraft  has  tremen¬ 
dous  possibilities.  The  job  of  MC  is  just  too  complex.  It  requires  too  much  spe¬ 
cific  knowledge  in  too  many  areas  for  one  person  to  be  able  to  manage  it  all.  This 
has  been  recognized  by  the  division  of  responsibilities  into  material  control, 
maintenance  control,  and  maintenance  administration,  but  even  these  divisions 
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are  becoming  inadequate  as  managers  arc  overloaded  with  programs,  data,  & 
requirements.  Most  MCCs  rely  on  other  subject  matter  "experts"  to  help  them 
when  they  need  information  about  a  specific  area.  This  is  to  aid  them  in  making 
decisions.  What  happens  when  such  expertise  is  not  available  EXACTLY  when 
it's  needed?  You  'punt'  as  it's  commonly  called,  or  make  a  wild  guess.  In  aca¬ 
demic  parlance  you  satisfice-pick  the  best  guess  you  can  and  make  do  with  it. 
Alternatively,  you  wait  until  the  expert  is  available,  which  has  all  the  potential 
drawbacks  associated  with  a  delayed  decision,  such  as  missing  a  launch  or 
launching  late. 

How  can  this  problem  be  solved?  Find  a  way  to  make  the  expert 
available  to  all  who  need  the  knowledge  anytime  they  might  need  it.  The  cost  of 
doing  this  with  people,  just  in  the  sheer  numbers,  not  to  mention  the  cost  of 
training  and  retaining,  is  obviously  prohibitive.  Furthermore,  based  on  past  ex¬ 
perience.  in  spite  of  the  best  intentions  in  attempting  to  accomplish  this  desirable 
objective,  we  have  not  been  100  percent  successful.  In  other  words,  some  OMAs 
still  lack  the  required  expert.  An  alternative  is  to  leverage  the  experts  we  do  have 
in  such  a  manner  that  they  do  not  need  to  be  there,  on  site,  or  even  av  ailable  by 
phone.  Here  is  where  an  ES  can  help.  Expert  systems  are  the  means  to  leverage 
our  experts. 

Several  questions  will  have  to  be  answered  for  any  expert  system  in¬ 
corporated  within  OASIS.  They  include: 

•  Who  will  champion  the  project?  In  other  words,  who  for  what  office)  will 
undertake  to  convince  the  people  with  funding  to  support  development  of 
an  expert  system? 

•  Who  will  be  the  knowledge  engineers?  Who  will  translate  the  experts' 
knowledge  into  an  expert  system? 
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•  The  knowledge  engineers  will  likely  not  be  in  sufficient  quantity  to  gather 
all  the  knowledge  from  the  maintenance  experts.  Who  will  serve  as  appren¬ 
tice  knowledge  engineers,  helping  the  knowledge  engineers,  and  in  the  proc¬ 
ess  become  knowledge  engineers  themselves? 

•  Who  will  be  the  maintenance  experts  from  whom  the  knowledge  is  gathered? 
Will  they  be  available?  Can  they  be  convinced  of  the  need  for  an  expert 
system,  and  thereby  lend  their  full  support?  Will  their  bosses  allow  them  to 
work  on  an  ES  development  project  that  may  detract  from  their  performance 
of  their  normal  duties? 

•  Are  the  existing  (or  planned)  databases  sufficient  for  the  needs  of  the  ES, 
or  will  they  have  to  be  developed  also? 

•  Who  will  keep  the  database(s)  in  the  ES  up-to-date? 

•  Who  will  provide  the  post  deployment  support  for  the  ES? 

•  Who  will  keep  the  knowledge  base  up-to-date? 

•  Who  will  decide  what  knowledge  will  be  included,  and  when  changes  to  that 
knowledge  base  are  appropriate? 


An  ES  will  require  as  part  of  its  database,  the  maintenance  history 
of  each  aircraft.  Whether  this  history  is  down-loaded  from  the  AV-3M  system, 
or  extracted  from  the  Naval  Aviation  Logistics  Data  Analysis  (NAL  DA)  system, 
or  is  collected  on  site  in  a  local  database  as  part  of  the  Maintenance  Activity 
Module,  needs  to  be  determined.  An  expert  system  can  resolve  uncertainty  in  one 
of  two  ways.  Either  the  needed  probabilities  are  encoded  in  the  knowledge  base 
or  the  ES  extracts  data  from  the  database  and  calculates  the  probabilities  as 
needed.  Since  the  Maintenance  Activity  Module  and  the  Flight  Activity  Module 
will  hold  much  of  the  data  the  ES  will  need,  they  will  have  to  be  developed  before 


or  concurrent  with  the  ES. 


g.  Traditional  Development  versus  Prototyping 

(1)  Traditional  Development.  The  traditional  systems  develop¬ 
ment  life  cycle  as  presented  by  Whitten,  Bentley  and  Ho  is  a  "generalized 

problem-solving  approach. ..[that  has]. ..eight  steps  or  phases: 

1.  Survey  the  situation. 

2.  Study  the  current  system. 

3.  Define  user  requirements. 

4.  Evaluate  alternative  solutions. 

5.  Select  new  computer  equipment  and  software  (if  necessary). 

6.  Design  the  system. 

7.  Construct  the  system. 

S.  Deliver  the  new  system."  [Ref.  13:  pp.  142-155] 

Note  that  this  approach,  in  contrast  to  the  information  engi¬ 
neering  (IE)  approach  described  earlier,  places  emphasis  on  the  current  situation 
and  systems  first.  (IE  on  the  other  hand,  eschews  deriving  the  new  system  from 
the  old  in  favor  of  emphasizing  the  organization's  information  needs.)  With  this 
approach  the  end-users  are  mentioned  or  implied  only  twice,  when  defining  their 
requirements  and  when  delivering  the  system.  One  of  the  techniques  used  in  the 
traditional  approach  to  help  define  user  requirements  has  been  a  prototype. 

(2)  Prototyping.  The  best  way  to  get  user  input  is  to  let  users  see 
what  is  possible.  Providing  them  a  quick  and  dirty  prototype  that  shows  them 
what  is  available  would  gcneiate  discussions  about  real  requirements  and  nicc- 
to-have  requirements  and  would  likely  provide  meaningful  user  input.  This  will 
also  get  people  thinking  about  possibilities.  Providing  a  prototype  of  OASIS  to 
all  400  plus  OMAs  is  obviously  prohibitive.  However,  a  single  one  could  be  taken 
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to  the  major  Naval  Air  Stations  for  demonstration  and  comment.  The  Wing 
(TYCOM)  Maintenance  Officer  can  host  conferences  of  MCCs  and  MMCOs  to 
present  the  idea  and  solicit  input,  feedback.  Using  a  prototype  to  define  and  re¬ 
fine  requirements  is  the  best  development  method  to  use.  A  prototype  is  a  rela¬ 
tively  inexpensive  way  to  make  sure  the  early  planning  is  correct,  and  thereby 
avoid  some  of  the  problems  that  have  plagued  other  projects  in  their  later  stages. 

Another  particularly  telling  point  about  end-users  and  proto¬ 
typing  should  be  made.  The  end-user  is  an  expert  in  his  field,  not  information 
systems  or  information  systems  development.  By  asking  them  what  they  want, 
we  can  expect  only  some  generalities.  So,  we  should  take  those  generalities  (since 
they  are  all  we  can  get)  build  a  prototype  of  what  we  think  they  want,  and  give 
it  to  them  to  use  and  critique.  As  their  needs  begin  to  crystallize,  so  will  the  in¬ 
formation  system  to  satisfy  those  needs. 

Turban  [Ref.  22:  p.  150]  differentiates  between  two  types  of 
prototypes,  throwaway  and  evolutionary. 

(3)  Throwaway  Prototypes.  The  throwaway  prototype  is  built 
and  used  once.  Its  purpose  is  to  get  information  from  the  users  about  the  system 
they  really  envision.  Once  the  requisite  amount  of  information  has  been  col¬ 
lected,  the  prototype  is  discarded.  As  Brooks  says, 

The  management  question,  therefore,  is  not  whether  to  build  a  pilot  system 
and  throw  it  away.  You  will  do  that.  The  only  question  is  whether  to  plan 
in  advance  to  build  a  throwaway,  or  to  promise  to  deliver  the  throwaway  to 
customers.  Seen  this  way,  the  answer  is  much  clearer.  Delivering  the 
throwaway  to  customers  buys  time,  but  it  does  so  only  at  the  cost  of  agony 
for  the  user,  distraction  for  the  builders  while  they  do  the  redesign,  and  a  bad 
reputation  for  the  product  that  the  best  redesign  will  find  hard  to  live  down. 

Hence  plan  to  throw  one  awav;  you  will,  anyhow.  [Ref.  44: 

P-  H6] 
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(4)  Evolutionary  Prototypes.  Another  approach  to  prototyping 
is  called  evolutionary  [Ref.  22:  pp.  150-152].  This  is  where  a  prototype  is  built  to 
perform  what  are  thought  to  be  the  most  important  functions  and  given  to  the 
user  to  use  and  critique.  Based  on  the  user's  critiques,  the  prototype  is  changed 
and  returned  to  the  user.  This  process  of  continually  improving  the  system  is 
repeated  until  the  users  agree  that  they  have  what  they  want.  Then  the  system 
is  integrated  with  others  to  form  the  "final"  system25. 

An  additional  benefit  to  this  approach  is  that  as  we  attempt  to 
put  what  they  want,  and  how  they  do  business,  into  a  system  we  (and  they)  may 
find  that  the  process  they  are  currently  using  really  does  not  work  the  way  they 
think  it  does  and  needs  to  be  changed.  Commensurate  with  re-thinking  the  cur¬ 
rent  process,  is  the  need  for  the  system  itself  to  be  flexible  enough  to  accommo¬ 
date  the  changes  in  the  process  that  may  come  to  light  during  development. 

(5 )  Pre-Prototype  Survey.  Before  building  a  prototype  the  users 
must  still  be  consulted  about  what  they  would  like  the  system  to  do  for  them. 
Since  the  OMAs  are  so  geographically  dispersed  (literally  around  the  world) 
travelling  to  each  of  them  to  personally  gather  their  responses  would  be  prohibi¬ 
tive.  Therefore  another  way  to  get  the  initial  desires  must  be  used.  A  survey  of 
all  the  OMAs,  by  Naval  message  or  letter  would  provide  a  starting  point  for 
building  the  prototype.  There  are  a  variety  of  questions  that  could  be  asked  in 
such  a  pre-prototype  survey.  They  include: 

25  In  terms  of  the  entire  life  cycle  of  the  system,  using  the  term  final  is  incorrect,  since  there 
will  in  fact  be  alterations.  However,  final  is  often  used  to  refer  to  the  version  of  the  system  that 
did  or  will  exist  when  the  system  reaches  a  particular  milestone  in  its  life.  That  version  is  the  final 
version  of  that  phase  of  the  system  s  hfe  cycle. 
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•  What  decisions  need  the  most  support,  or  are  the  most  difficult  and  require 
consulting  an  expert?  (The  goal  of  this  question  is  to  find  out  by  simply 
counting  the  votes,  which  areas  of  maintenance  would  benefit  most  from  an 
expert  system.) 

•  What  would  the  MCCs  would  like  to  see  automated?  (This  question  is  a 
wide  open  one,  and  may  need  to  have  a  few  examples  to  prompt  answers. 
The  level  of  response  and  specific  answers  could  be  used  to  assign  priorities 
to  the  different  modules  of  OASIS,  expert  systems  included.) 

•  How  much  and  what  type  of  support  and  training  would  they  like.  (Again 
examples  would  be  useful  to  prompt  responses,  but  this  could  be  used  to  as¬ 
sess  the  level  of  post  deployment  support  they  expect.) 

•  What  is  the  opinion  of  upper  management,  specifically  the  CO  and  XO  with 
regard  to  the  ability,  experience  and  performance  of  their  maintenance  or¬ 
ganization?  (This  question  will  provide  a  view  of  the  "real"  quality  of  the 
experts  out  there,  and  may  also  help  identify  those  maintenance  profes¬ 
sionals  who  should  be  tasked  with  being  "experts"  for  the  development  of  the 
system.) 

•  Do  COs.  XOs,  OPSOs,  and  MOs  get  the  information  they  when  they  need 
it  and  do  they  have  confidence  in  it?  (This  question  accomplishes  two  goals 
if  answered.  First,  the  response  will  provide  a  measure  of  the  "climate"  into 
which  we  intend  to  place  OASIS,  i.e..  how  receptive  the  commands  are  to 
computers  and  automation.  Second,  it  will  provide  us  with  a  measure  of 
what  upper  managers  think  is  important.  They  too  are  customers  of  OASIS, 
expert  system  included,  and  if  we  build  those  modules  that  respond  to  both 
upper  management  and  the  MCCs,  acceptance  of  the  system  will  be  greater.) 

•  A  question  that  could  be  asked  of  COs  only  is  whether  or  not  they  would  like 
to  have  more  and  possibly  better  "expert"  help  on  call.  WITHOUT  the 
'stigma'  of  asking  for  help  and  hanging  their  'dirty  laundry'  out?  (This 
question  is  another  one  to  assess  the  perceived  need  for  more  quality  main¬ 
tenance  professionals.) 

•  What  information  is  of  most  value  to  maintenance  control  chiefs,  and  do 
they  get  it  when  they  need  it,  in  a  form  they  can  use?  (This  would  give  an 
indication  of  which  modules  to  build  first,  and  which  interfaces  should  be 
developed  first.) 

«  What  equipment  do  the  OMAs  have  now?  This  will  involve  an  inventory 
of  the  hardware  and  software  currently  held  at  each  OMA.  (This  question 
would  provide  an  indication  of  potential  prototype  sites,  as  well  as  an  indi¬ 
cation  of  the  additional  equipment  that  will  be  needed  to  implement  OASIS 
at  each  site.) 
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h.  Cost-Benefit 

This  project  must  eventually  graduate  from  research  project  to  de¬ 
ployed  system.  To  do  so  it  will  have  to  be  justified  and  funded.  Therefore, 
NAMO,  or  whichever  activity  sponsors  OASIS,  will  have  to  begin  including 
OASIS  in  its  budgeting  process  soon.  In  addition,  a  detailed  cost-benefit  analysis 
will  have  to  be  done.  Rather  than  wait  until  the  last  minute  and  try  to  remember 
what  various  costs  have  been  so  that  future  costs  can  be  predicted,  do  one  now 
and  kept  it  updated  as  the  project  progresses.  Several  methods  of  cost-benefit 
analysis  are  available.  Payback  analysis,  return-on-investment  analysis,  and 
present  value  analysis  are  just  three  [Ref  13:  pp.  796-802].  The  best  of  these  is 
present  value  analysis:  the  other  two  have  limitations.  The  de  facto  guide  in  the 
Navy  is  Economic  Analysis  Procedures  for  ADP  [Ref.  56],  It  provides  very  ex¬ 
plicit  "how-to"  guidance  for  performing  economic  analysis  of  ADP  systems. 

Some  of  the  potential  benefits  of  OASIS  include  increased  readiness, 
more  timely  and  accurate  readiness  figures,  and  better  maintenance  decisions  at 
operating  lex  els  resulting  in  less  waste,  more  effective  parts  usage,  and  fewer  re¬ 
pairs  being  made  by  black  box  changing  vice  true  troubleshooting.  Though  dif¬ 
ficult  to  quantify,  a  reasonable  attempt  must  be  made.  Estimating  what  an 
additional  one  percent  improvement  in  readiness  costs  will  likely  be  necessary  to 
help  higher  authorities  determine  the  costs  of  increased  readiness  that  will  result 
from  implementing  OASIS.  Costs  are  much  easier  to  identify  and  include  the 
obvious  direct  costs  of  hardware  and  software,  as  well  as  some  not  so  obvious 

* 

ones  such  as  supplies,  telephone  calls,  and  postage  that  will  be  used  during  de¬ 
velopment. 
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Allen  and  McSwain  recommended  value  analysis  be  used  to  evaluate 
a  DSS/ES  [Ref.  7:  pp  87-88].  Value  analysis  focuses  on  the  minimum  benefits  to 
be  achieved  by  a  system  in  order  to  be  considered  successful.  Next  the  maximum 
amount  the  user  is  willing  to  pay  for  each  benefit  is  determined.  Assuming  that 
the  costs  are  within  limits,  a  prototype  is  then  built.  The  value  analysis  process 
can  be  looked  at  as  formalized  intuition,  but  is  still  less  rigorous  than  the 
cost  benefit  techniques  listed  above.  [Ref.  20:  pp.  165-167] 
i.  Additional  Systems 

Proposals  have  been  advanced  to  develop  systems  that  would  address 
various  areas  of  aircraft  maintenance  management,  but  none  of  them  has  yet 
been  implemented.  Several  of  them  are:  Aviation  Squadron  Enlisted  Training 
System  (ASETS)  [Ref.  57];  an  expert  system  for  assigning  personnel  to  squadron 
detachments  [Ref.  33]:  an  expert  system  for  scheduling  maintenance  actions  [Ref. 
6]:  a  decision  support  system  expert  system  for  maintenance  controls  [Ref.  7]:  and 
a  system  now  being  proposed  as  a  thesis  project  at  Naval  Postgraduate  School  for 
matching  an  activity's  Manpower  Authorization  (MPA)  to  the  actual  personnel 
on  board  [Ref.  52]. 

2.  Preliminary  Plan 

If  we  apply  the  information  engineering  methodology  to  the  OMA  busi¬ 
ness''  we  will  find  a  pyramid  with  many  small  projects  at  the  base.  All  of  these 
can  be  developed  under  the  umbrella  of  OASIS.  This  is  when  the  crucial  step  is 
taken.  As  Mr.  Finkelstein  advocated  in  his  presentation  in  June  1989,  assign  a 
priority  to  each  of  the  small  projects,  and  concentrate  effort  on  developing  those 
small  projects  from  start  to  finish,  progressing  from  one  project  to  the  next  in  or- 


dcr  of  the  assigned  priorities  The  highest  priority  should  be  given  to  those 
modules  that  have  been  identified  by  the  end-users,  or  those  deemed  by  higher 
authority  to  have  the  greatest  impact  on  accomplishment  of  the  OMA's  strategic 
goals.  (Or,  if  necessary,  the  projects  that  will  have  the  greatest  visibility  with  the 
people  controlling  the  funding.) 

One  of  the  benefits  of  developing  a  modular  plan  to  satisfy  the  functional 
requirements  of  an  information  system  is  that  any  module  can  be  developed  in¬ 
dependently  of  the  others.  Although  a  more  detailed  data  analysis  is  still  re¬ 
quired,  the  module  organization  presented  here  is  based  on  data  dependencies. 
The  only  module  that  may  be  dependent  on  another  is  one  using  ES  techniques 
that  require  that  a  database  be  developed  first  (or  at  least  concurrently).  Such 
is  the  case  with  the  proposed  expert  system  in  the  Maintenance  Activity  Module, 
for  example.  It  must  have  available  aircraft  historical  data,  personnel  training 
and  qualification  data,  flight  activity  data,  and  asset  status  data  to  be  of  real 
value  to  MCCs. 

Applying  the  same  priority  stated  in  “C.  OASIS  MODULE 
DESCRIPTIONS-’  on  page  65,  ,<e  human  resources  modules  should  be  devel¬ 
oped  first,  followed  by  financial  management  modules,  material  management 
modules,  and  finally  the  utility  mode’e.  However,  visibility  has  a  lot  to  do  with 
a  system's  success  with  sponsors  and  acceptance  by  users.  The  more  people  who 
sec  and  use  a  system,  the  higher  is  the  likelihood  that  it  will  become  accepted  and 
supported.  Although  in  the  long  run  personnel  issues  will  have  a  dramatic  impact 
on  an  OMA's  ability  to  perform,  those  issues  seldom  receive  the  sustained  visi¬ 
bility  that  aircraft  readiness  issues  do.  Accordingly,  the  first  modules  that  should 
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be  developed  are  those  that  have  high  visibility  in  terms  of  aircraft  readiness. 
Those  modules  are  the  Flight  Activity  Module,  the  Maintenance  Activity  Mod¬ 
ule,  and  the  Asset  Management  Module.  The  expert  system  portion  of  the 
Maintenance  Activity  Module  will  require  data  from  the  Flight  Activity  Module, 
the  Training  and  Qualifications  Module,  and  the  Asset  Management  Module,  so 
those  modules  should  be  developed  in  parallel  with  the  ES  in  the  Maintenance 
Activity  Module.  Considering  the  fact  that  financial  management  is  bound  to 
be  consistently  important  (particularly  as  funds  become  fewer  and  fewer),  the 
Financial  Management  modules  should  be  developed  next.  The  utility  module 
functions  should  be  developed  as  needed  to  support  the  rest.  Finally  the  Per¬ 
sonnel  Management  Module  should  be  developed.  The  benefit  of  the  modular 
organization  deserves  added  emphasis.  Each  of  these  modules  can  be  developed 
independent  of  the  others  (with  the  sole  exception  of  the  expert  systems),  as  long 
as  it  is  developed  under  the  umbrella  of  an  over  all  plan  that  will  make  future 
integration  of  the  different  modules  easy.  OASIS  is  such  a  plan. 

Information  engineering  is  the  most  promising  development  methodology 
to  use,  and  is  the  most  consistent  with  the  modular  framework  proposed.  Addi¬ 
tionally,  taking  the  evolving  prototype  approach  will  allow  a  system  to  be  devel¬ 
oped  that  meets  the  real  needs  of  the  end-users,  not  the  needs  of  the  users  as 
perceived  by  a  systems  developer.  In  short,  build  a  quick  and  dirty  prototype  and 
get  it  out  to  the  fleet  (OMAs).  Let  the  users  propose  changes  and  improvements, 
make  those  changes,  and  repeat  the  process  until  an  acceptable  level  of  stability 
is  reached,  and  then  go  on  to  the  next  module.  A  good  place  to  start  would  be 
with  CANDES.  It  already  has  support  and  visibility,  is  already  being  implc- 


mcntcd,  and  more  importantly,  is  the  data  collection  portion  of  one  of  the  mod¬ 
ules  (Flight  Activity)  recommended  above  for  immediate  development.  The 
benefits  of  just  collecting  the  NAVFLIR  data  at  the  source  are  becoming  obvious. 
Results  through  January  from  the  first  test  sites  indicate  that  what  used  to  be  a 
10-20  percent  error  rate  is  now  zero  [Ref.  54],  The  aircrew,  or  whoever  enters  the 
flight  data,  aren't  allowed  to  make  errors.  The  errors  are  trapped  right  at  the 
source.  This  allows  all  the  people  who  were  involved  in  the  post  entry  checking 
process  to  perform  other  tasks,  or  to  do  those  other  tasks  better  now  that  they 
don't  spend  as  much  time  fixing  errors.  That  system  should  now  go  through  user- 
initiated  improvements  while  the  rest  of  the  functions  of  the  Flight  Activity- 
Module  are  added. 

3.  Potential  Problems  and  Benefits 

This  section  will  highlight  some  of  the  potential  problems  and  pitfalls  that 
must  be  overcome  if  OASIS  is  to  be  successfully  developed  and  implemented. 
Some  of  these  issues  have  been  previously  mentioned,  but  they  are  important 
enough  to  warrant  additional  and  separate  discussion. 
a.  Audit  Trail  and  Signature  Requirements 
The  requirement  for  an  audit  trail  could  be  a  potential  problem. 
Signatures  arc  required  at  various  points  in  the  use  and  repair  of  aircraft.  A  pilot 
must  sign  for  the  aircraft,  an  inspector  must  sign  that  he  has  completed  the  in¬ 
spection  in  accordance  with  applicable  instruction,  and  only  designated  personnel 
(typically  MCCs)  arc  authorized  to  release  an  aircraft  to  a  pilot  as  safe  to  fly. 
Provision  must  be  made  for  obtaining  these  signatures,  or  some  other  way  for 
these  "special  events"  to  be  marked  must  be  found.  A  simple  way  would  be  to 
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issue  passwords  to  those  authorized  to  sign  a  form.  The  system  would  ask  for  the 
password  anytime  someone  attempted  to  complete  that  block.  Each  person's 
password  would  cause  their  name  to  appear  in  that  space.  Doubters  would  ask 
what  is  to  prevent  an  unauthorized  person  from  using  another's  password.  The 
answer  is  nothing.  However,  aviation  maintenance  has  always  relied  on  the  idea 
of  special  trust  and  confidence  when  granting  the  authority  to  individuals  to  cer¬ 
tify  certain  events  with  their  signature.  That  same  special  trust  and  confidence 
would  apply  to  the  issuance  of  passwords.  The  basic  elements  of  any  good  pass¬ 
word  security  system  would  have  to  be  applied,  but  not  in  such  a  way  as  to 
undermine  that  special  trust  and  confidence  that  is  so  essential  to  effective  avi¬ 
ation  maintenance.  For  those  who  remain  unconvinced,  absolute  security  can  be 
purchased,  but  at  a  price.  Signature  recognition  and  verification  devices  are  a 
possible  solution  to  this  problem,  in  that  only  with  a  signature  that  the  system 
recognizes  as  appropriate  for  that  event  would  the  event  show  as  completed  in  the 
system.  It  may  be  impossible  to  totally  eliminate  paper  from  the  aircraft  flying 
and  maintaining  cycle,  but  it  can  certainly  be  reduced. 
b.  Availability  of  Experts 

For  areas  where  ESs  arc  appropriate,  a  potential  problem  is  the  dif¬ 
ficulty  of  convincing  upper  management  to  let  go  of  their  expert  for  the  time  it 
will  take  to  build  the  system.  Inevitably,  the  expert  you  need  is  the  one  in  highest 
demand  [Ref.  58:  p  200.].  This  hesitancy  must  be  overcome  by  either  1)  con¬ 
vincing  upper  management  that  the  long  term  gain  far  outweighs  the  short  term 
pain,  or  2)  getting  upper  management's  bosses  to  convince  them.  Another,  less 
optimum  solution  is  to  develop  the  expert  system  with  limited  access  to  the 
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expert(s).  This  would  increase  the  number  of  iterations  required,  and  unneces¬ 
sarily  prolong  development. 

c.  Prototype  Transition 

Another  issue  that  must  be  addressed  is  how  and  when  prototypes, 
or  even  fully  developed  systems  (expert  or  others)  built  at  the  Naval  Postgraduate 
School  should  transition  from  NPS  to  full  fledged  fleet  system  support.  A  second 
part  of  this  issue  is  what  activity  in  the  information  systems  hierarchy  of  the 
Navy  is  going  to  take  over  the  support  of  those  systems.  Quantity  and  quality 
of  accompanying  documentation  will  need  to  be  addressed.  In  other  words,  just 
because  the  system  is  developed  at  NPS  does  not  relieve  NPS  of  satisfying  the 
same  requirements  a  commercial  contractor  would  have  to  meet  in  fulfilling  a 
contract  for  the  system.  (A  more  compelling  reason  for  turning  over  a  top  notch 
system  is  the  need  for  NPS  students  and  faculty  to  practice  what  is  being 
preached  in  the  information  systems  curriculum  at  NPS.)  This  problem  would 
be  effectively  answered  if  NAMO  does  in  fact  take  on  CDA  responsibilities  for 
OASIS.  Then,  NPS-dcvcloped  applications  would  have  to  meet  the  same  re¬ 
quirements  as  an  application  sent  to  NAMO  by  an  OMA. 

d.  Procedure  Correction 

Aviation  maintenance  may  benefit  from  just  the  process  of  developing 
OASIS.  We  may  find,  by  going  through  the  iterative  prototyping  process  with 
the  end-users,  that  the  way  we  are  doing  business  now  has  some  basic  flaws.  As 
Deming  [Ref.  59:  pp.  9-10]  and  others  have  emphasized,  automating  a  flawed 
process  merely  allows  the  flaws  to  manifest  themselves  faster  once  the  system  is 
in  operation.  This  is  not  to  imply  that  the  maintenance  process  is  flawed  and 
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needs  to  be  evaluated.  That  process  is  in  fact  being  constantly  evaluated  under 
the  most  demanding  conditions,  namely,  daily  flight  operations.  However,  if  we 
have  accepted  faulty  procedures  as  the  way  some  things  must  be  done,  attempting 
to  automate  those  procedures  in  the  literal  and  inflexible  realm  of  computerized 
information  systems  may  require  that  we  finally  change  and  maybe  even  stream¬ 
line  those  procedures. 

E.  SUMMARY 

In  summary,  strategic  planning  for  OMAs  must  precede  strategic  information 
systems  planning.  Those  strategic  information  plans  are  then  translated  into 
functional  requirements.  Finally  an  information  system  that,  through  this  top- 
down  process,  meets  the  information  needs  of  the  organization,  is  planned,  de¬ 
veloped  and  implemented.  Information  engineering  provides  an  organized  and 
formal  method  to  perform  the  top-down  information  analysis  necessary  to  de¬ 
velop  a  flexible  and  responsive  information  system. 

NALCOMIS,  developed  using  the  traditional  problem  solving  approach  to 
information  systems  development,  attempted  to  satisfy  all  the  requirements  in  one 
system  developed  all  at  one  time.  For  whatever  reason,  loss  of  funding,  taking 
too  long,  or  too  many  changes  to  the  specific  requirements,  it  has  not  been  fielded 
for  the  OMAs. 

Contrasted  with  the  traditional  problem  solving  approach  is  that  of  iterative 
prototyping.  This  maintains  continuous  end-user  involvement,  and  coupled  with 
information  engineering,  has  the  potential  to  deliver,  in  a  start-small-and-grow 
fashion,  the  tools  OMA  managers  need  to  effectively  apply  their  resources  to  ac¬ 
complishing  CNO  readiness  and  safety  goals. 


The  preliminary  module  descriptions  and  implementation  plan  for  OASIS  has 
been  presented.  The  preliminary  plan  recommends  developing  first  those  mod¬ 
ules  that  will  have  the  greatest  impact  in  terms  of  both  visibility  and  usefulness. 
Finally,  the  potential  pitfalls  of  an  audit  trail,  signature  requirements,  expert 
availability,  prototype  transition,  post  deployment  software  support  were  high¬ 
lighted  so  that  they  can  be  avoided. 
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V.  RECOMMENDATIONS,  FURTHER  RESEARCH,  AND 

CONCLUSIONS 


A.  RECOMMENDATIONS 

Even  though  this  entire  proposal  is  a  recommendation  of  how  to  fill  the  au¬ 
tomated  information  management  void  at  OMAs,  there  are  still  a  few  recomm¬ 
endations  that  will  help  focus  the  effort  of  those  that  follow.  The  first  is  that 
since  we  have  within  the  Navy  the  resources  to  develop  OASIS,  it  should  be  de¬ 
veloped  within  the  Navy.  We  have  the  people  with  the  knowledge  of  aviation 
maintenance.  We  have  a  growing  number  of  people  with  information  systems 
knowledge.  Furthermore,  advancing  technology  is  providing  us  with  the  hard¬ 
ware  and  software  advances  that  make  developing  OASIS  not  only  imperative, 
but,  relative  to  15  years  ago,  easy. 

The  second  recommendation  is  not  original.  It  is  something  that  information 
systems  developers  have  learned  with  painful  slowness.  Involve  the  users.  This 
means  more  than  asking  them  what  they  want.  It  means  getting  them  involved 
on  day  one  and  keeping  them  involved  throughout  the  life  of  the  system.  As 
discussed,  the  most  effective  way  to  do  that  is  through  iterative  prototyping. 
Therefore,  do  not  waste  any  time  fielding  a  prototype  and  using  iterative  proto¬ 
typing  to  keep  the  users  involved. 

The  third  recommendation  derives  from  the  fact  that  the  users  of  OASIS  are 
not  those  at  the  IMAs.  not  those  in  supply,  not  those  at  higher  level  commands, 
but  the  maintainors  at  the  OMAs.  Accordingly,  the  requirements  that  determine 
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the  functions  OASIS  performs,  and  the  order  and  manner  in  which  those  func¬ 
tions  are  developed  must  come  from  the  OMA  maintenance  professionals.  Do 
not  let  OASIS  be  driven  by  the  reporting  requirements  of  higher  authority  or  by 
the  interface  requirements  of  any  other  system.  Those  are  all  only  small  parts  of 
OASIS.  OASIS  is  for  "the  guys  in  the  trenches." 

The  fourth  recommendation  is  that  once  aviation  maintenance  officers  have 
been  selected  to  attend  the  Naval  Postgraduate  School  they  should  be  contacted 
and  briefed  about  the  OASIS  project  and  the  potential  for  them  to  get  an  early 
start  on  their  thesis  by  working  on  some  part  of  OASIS.  This  can  be  best  ac¬ 
complished  through  liaison  between  the  OASIS  developers  and  the  aviation 
maintenance  officer  detailer.  This  is  not  to  suggest  excluding  anyone  else  from 
working  on  a  part  of  OASIS,  only  to  suggest  that  the  aviation  maintenance  offi¬ 
cer  community  is  small  enough  that  marketing  OASIS  as  thesis  material  is  man¬ 
ageable.  The  student  will  benefit  from  knowing  the  topic  of  his  her  thesis  and 
having  a  ready  topic  for  class  projects  and  papers.  The  OASIS  project  will  ben¬ 
efit  from  having  people  work  on  the  project  who  do  not  have  to  learn  aircraft 
maintenance  in  the  Na\y.  OASIS  will  also  benefit  from  keeping  academia  in¬ 
volved  and  thereby  ensuring  that  the  "leading  edge"  of  information  systems  tech¬ 
nology  is  applied  to  OASIS. 

B.  AREAS  FOR  FURTHER  RESEARCH 

This  section  addresses  several  areas  that  warrant  further  research.  Each 
module  is  itself  at  least  one  project,  and  in  most  cases  several,  that  will  need  fur¬ 
ther  research.  Throughout  this  thesis,  areas  were  pointed  out  that  would  need 
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additional  study  or  effort.  Those  presented  here  are  in  addition  to  those  already 
discussed,  or  are  important  enough  to  repeat. 

1.  OMA  Information  Resource  Management 

One  of  the  alternatives  to  a  standardized  system  such  as  OASIS  is  for 
each  OMA  to  "do  its  own  thing"  with  respect  to  information  management.  One 
argument  in  favor  of  such  an  approach  is  that  in  spite  of  the  NAMP  standard, 
every  OMA  is  a  unique  organization  with  its  own  style  of  doing  things.  Another 
is  that  by  pushing  a  standard  system  we  would  be  removing  some  of  each  CO's 
leeway  in  managing  his  OMA.  On  the  other  hand,  the  question  of  whether 
OMAs  have  or  will  ever  have  enough  knowledge  of  information  systems  to  do 
their  own  planning  needs  to  be  answered.  Also  important  is  the  question  of 
whether  OMAs  should  be  doing  their  own  IRM  planning  and  IS  development. 
Further  study  into  how  IRM  should  fit  within  an  OMA's  management  could 
possibly  resolve  these  questions.  The  points  of  view  on  these  issues  will  range 
from  the  OMAs,  who  are  tired  of  waiting,  to  Operational  Commanders  (who 
would  probably  say  an  OMA  is  there  to  fight,  not  build  computer  systems.). 

2.  Evaluation  criteria. 

To  avoid  falling  into  the  trap  of  pouring  more  and  more  resources  into  a 
project  that  has  already  failed,  some  criteria  to  measure  the  success  of  OASIS 
should  be  decided  upon  at  the  outset.  Because  our  real  customers  are  the  end- 
users  in  the  OMAs  around  the  world,  their  satisfaction  should  be  the  primary 
measure  of  success.  However,  being  within  budget  and  on  schedule  are  also  im¬ 
portant  criteria.  How  to  measure  the  chosen  criteria  should  be  an  early  decision 
so  that  tracking  of  them  can  start  immediately.  Limits  should  be  established  be- 
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yond  which  specific  action  is  taken,  e.g.,  at  ten  percent  late  the  project  is  killed. 
What  these  criteria  should  be,  and  what  limits  should  be  established  falls  in  the 
field  of  software  engineering,  and  is  certainly  an  area  for  further  study. 

3.  Knowledge  Acquisition 

There  are  more  than  one  type  of  aircraft  in  the  Navy.  Each  has  its  own 
maintenance  experts,  and  even  among  those  experts  there  will  be  differences  of 
opinion  (and  heuristics)  about  the  way  to  solve  a  particular  problem.  Which  of 
these  experts  should  become  the  expert  for  an  ES?  Who  decides  who  the  expert 
is?  Should  there  be  more  than  one  expert  consulted  while  building  an  ES?  Once 
chosen,  will  "their"  ES  be  accepted  by  the  other  experts  who  were  not  chosen,  and 
thus  by  the  fleet?  Can  the  experts,  already  in  short  supply,  be  made  available  for 
the  time  it  takes  to  build  the  ES?  How  long  will  it  take  to  acquire  the  knowledge 
of  the  cxpert(s)?  These  arc  all  questions  that  must  be  answered  for  an  F.S  to  be 
developed.  Finding  the  answers  is  itself  a  topic  of  thesis  proportions,  and  worthy 
of  further  study. 

4.  Data  collection 

The  user  interface  of  OASIS  must  be  studied.  There  are  a  wide  v  ariety 
of  styles  available.  Some  people  prefer  typing  while  others  prefer  using  a  mouse 
or  track  ball.  Which  will  gain  more  user  acceptance,  or  should  both  be  offered? 
Should  the  video  screens  for  data  collection  look  exactly  like  the  paper  forms  in 
use  now,  or  should  the  data  be  collected  by  having  the  user  respond  to  a  scries 
of  questions.  Will  the  answers  be  typed  in  by  the  user,  or  selected  from  a  list? 
Will  a  paper  copy  be  required?  What  backup  method  will  be  used?  How  exten¬ 
sive  and  sophisticated  should  the  security  system  be?  How  many  data  collection 
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points  should  there  be  (a  subject  for  queuing  theory)  to  satisfy  the  peaks  and 
troughs  of  data  entry,  e.g.,  when  ten  aircrew  want  to  fill  in  their  flight  data?  Will 
the  aircrew  even  have  to  fill  it  in  anymore?  Similar  surges  in  data  entry  can  be 
expected  near  shift  changes  and  meal  times  as  maintenance  personnel  try  to 
complete  their  "paperwork."  Since  the  user  interface  is  in  reality  the  most  visible 
part  of  the  system  to  the  user,  extensive  study  should  be  done  to  determine  the 
optimum  mix  of  available  options. 

5.  Implementation  and  Post  Deployment  Software  Support 

Although  mentioned  earlier,  this  issue  is  important  enough  to  be  ad¬ 
dressed  specifically.  The  exact  method  of  implementation  for  OASIS  needs  to 
be  studied.  Over  400  OMAs  will  eventually  benefit  from  OASIS  (or  a  similar 
system).  They  can  not  all  be  a  prototype  site.  Should  use  of  OASIS  be  manda¬ 
tory  or  optional?  What  is  the  best  method  of  implementation  to  ensure  its  effec¬ 
tive  use?  User  involvement  can  only  go  so  far  with  so  diverse  and  disbursed  a 
group  of  end-users. 

Current  IS  assets  at  OMAs  range  from  very  basic  combinations  of  hard¬ 
ware  and  software  to  ones  that  arc  very  sophisticated.  An  analysis  of  the  ex¬ 
pected  hardware  and  software  requirements  for  OASIS  must  be  performed.  Then 
those  requirements  must  be  compared  to  what  OMAs  already  have.  Finally,  an 
acquisition  plan  must  be  developed  to  ensure  that  all  OMAs  have  the  necessary 
hardware  and  software  to  implement  OASIS  before  OASIS  is  available  to  them. 
Considering  the  budget  process  in  DOD,  this  plan  must  be  developed  early  in  the 
OASIS  development  in  order  to  have  the  funding  approved  by  the  time  OASIS 
is  ready  for  implementation. 
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The  point  at  which  an  information  system  is  delivered  to  a  customer  is 
when  the  major  part  of  the  work,  on  that  system  begins.  The  system  must  be 
maintained,  changes  in  the  customer's  procedures  must  be  incorporated,  and  er¬ 
rors  that  are  found  after  delivery  must  be  fixed.  If  a  system  takes  one  year  to 
develop  and  deliver,  and  it  is  expected  to  be  in  use  for  nine  additional  years,  then 
ninety  percent  of  its  life  is  post-delivery.  Hardware  is  not  normally  the  problem; 
software  is.  How  OASIS  will  be  supported  needs  to  be  determined.  Alternatives 
should  be  identified,  evaluated,  and  finally  a  decision  must  be  made  early  enough 
in  the  development  so  that  the  support  can  be  in  place  and  ready  when  OASIS 
is  deployed.  This  will  mean  keeping  the  PDSS  activity  (or  activities)  as  involved 
as  the  end-users,  if  not  more  so,  throughout  the  development.  With  respect  to 
expert  systems,  who  will  maintain  the  knowledge  base?  Will  we  have  to  dedicate 
an  expert  to  it,  or  can  experts  be  consulted  as  needed  by  a  knowledge  engineer? 
When  changes  have  been  made,  who  will  authorize  distributing  them  to  the  fleet, 
and  how  will  it  be  done?  These  issues  must  all  be  resolved  before  OASIS  is  ready 
to  be  implemented,  and  are  ideal  candidates  for  further  study. 

6.  OASIS  at  AMO  School 

The  Navy's  school  for  Aviation  Maintenance  Officers  could  play  a  role 
in  the  development  and  support  of  OASIS.  As  the  new  maintenance  officers  go 
through  this  school  they  could  learn  how  OASIS  works,  and  not  have  to  learn 
by  trial  and  error  once  at  an  OMA.  Additionally,  since  the  school  is  staffed  and 
taught  by  fleet  experienced  maintenance  personnel,  their  ideas  and  suggestions 
would  be  invaluable  to  both  the  initial  development  and  the  post  deployment 
support.  They,  unlike  their  peers  still  at  OMAs,  may  be  able  to  devote  time  to 
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such  a  project  without  detracting  from  their  performance.  Encouraging  them  to 
constructively  critique  OASIS  and  become  actively  involved  in  the  system  could 
help  overcome  their  reluctance,  while  still  at  an  OMA,  to  1)  put  themselves  on 
report  by  advertising  problems,  and  2)  take  the  time  from  their  hectic  crisis- 
ridden  daily  jobs  to  submit  changes  to  the  systems  that  are  supposed  to  help 
them. 

C.  CONCLUSIONS 

The  strategic  goal  of  an  Organizational  Maintenance  Activity  is  to  achieve 
and  maintain  Chief  of  Naval  Operations  standards  of  readiness  and  safety. 
Achieving  that  goal  requires  planning  the  effective  acquisition  and  use  of  re¬ 
sources.  One  of  the  resources  is  information.  Not  only  is  information  a  resource, 
but  also  timely,  accurate  and  relevant  information  is  vital  to  effective  manage¬ 
ment  of  the  other  resources,  specifically  aircraft,  people,  equipment  and  money. 

OMAs  are  tasked  with  managing  billions  of  dollars  of  physical  assets,  hun¬ 
dreds  of  people  and  their  training,  and  tremendous  inventories  of  parts,  supplies, 
publications  and  equipment  with  no  modern  management  tools  to  help.  The  need 
to  manage  the  information  resources  of  aviation  maintenance  managers  was 
formally  recognized  when  NALCOMIS  was  conceived.  Today,  the  only  question 
remaining  is  the  specific  information  system  that  will  provide  the  modern  tools, 
and  when  it  will  actually  be  implemented  at  OMAs. 

Information  systems  technology  has  made  phenomenal  advances  in  the  past 
15  years.  We  in  aviation  maintenance  must  capitalize  on  advances  in  structured 
analysis  methods,  information  engineering  techniques  and  artificial  intelligence 
tools.  Failure  to  do  so  would  be  a  tragedy. 
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Much  work  has  gone  into  the  assorted  information  systems  used  at  different 
aviation  maintenance  levels  and  activities.  Several  of  these  systems  can  prov  ide 
valuable  information  to  OMAs  and  should  be  tasked  with  doing  so  in  a  form  that 
can  be  used  by  OASIS. 

Undertaking  to  develop  an  information  system  complex  enough  to  support 
the  information  needs  of  Organizational  Maintenance  Activities  is  an  ambitious 
objective.  It  has  been  tried  before.  However,  by  reducing  the  project  to  modules 
of  manageable  size,  and  applying  the  concept  of  evolutionary  prototyping.  OMAs 
will  finally  reap  some  benefit.  As  more  modules  are  developed,  the  full  impact 
of  managing  information  effectively  will  be  realized.  We  must  fill  the  void 
intelligently,  but  QUICKLY.  OASIS  is  the  initial  step. 
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APPENDIX  A.  ACRONYMS  AND  ABBREVIATIONS 


AEMS 

AMMRL 

AMO 

AMRR 

ARS 

ASETS 

ATSS  II 

AV-3M 

BOR 

CANDES 

CD  A 

CD-ROM 

CIMP 

CNO 

CO 

CONUS 

DD/DS 

DOD 

DON 

DSS 

ES 

FRS 

IE 

IMA 

IMRL 

IRSTRATPLAN 


Aircraft  Engine  Management  System 
Aircraft  Maintenance  Material  Readiness  List 
Assistant  Maintenanace  Officer 
Aircraft  Material  Readiness  Report 
Aerial  Refueling  Stores 
Aviation  Squadron  Enlisted  Training  System 
Aviation  Training  Support  System— Phase  II 
Aviation  Maintenance  and  Material  Management 
Budget  OPTAR  Report 

Computer  Aided  NAVFL1R  Data  Entry  System 

Central  Design  Activity 

Compact  Disk-Read  Only  Memory 

Component  Information  Management  Plan 

Chief  of  Naval  Operations 

Commanding  Officer 

Continental  United  States 

Data  Dictionary  Directory  System 

Department  of  Defense 

Department  of  the  Navy 

Decision  Support  System 

Expert  System 

Fleet  Readiness  Squadron 

Information  Engineering 

Intermediate  Maintenance  Activity 

Individual  Material  Readiness  List 

Department  of  the  Navy  (DON)  Strategic  Plan  for  Man¬ 
aging  Information  and  Related  Resources 
(IRSTRATPLAN) 
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IS 

LAN 

LCM 

MAF 

MC 

MCC 

MDCS 

MDS 

MIS 

MO 

MPA 

MMCO 

MRS 

NADEP 

NADIS 

NALDA 

NAMO 

NAMP 

NAMSO 

NALCOMIS 


Information  System 

Local  Area  Network 

Life  Cycle  Management 

Maintenance  Action  Form 

Maintenance  Control 

Maintenance  Control  Chief 

Maintenance  Data  Collection  System 

Maintenance  Data  System 

Management  Information  System 

Maintenance  Officer 

Manpower  Authorization 

Maintenance  Material  Control  Officer 

Management  Reporting  System 

Naval  Aviation  Depot 

Naval  Aviation  Depot  Information  System 

Naval  Aviation  Logistics  Data  Analysis 

Naval  Aviation  Maintenance  Office 

Naval  Aviation  Maintenance  Program 

Naval  Aviation  Maintenance  Support  Office 

Naval  Aviation  Logistics  Command  Management  Infor¬ 
mation  System 


NALCOMPT 

NAVAIR 

NAVFLIR 

NAVMASSO 


Na\y  Comptroller 
Naval  Air  Systems  Command 
Naval  Flight  Information  Record 
Navy  Management  Systems  Support  Office 
NAVSEALOGCEN  Naval  Sea  Logisitics  Center 
NAVSO  Navy  Staff  Office 

NAVSUP  Naval  Supply  Systems  Command 

NMPC  Naval  Military  Personnel  Command 

NOAP  Naval  Oil  Analysis  Program 

NRMM  NALCOMIS  Repairables  Management  Module 
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OASIS 

OPTAR 

OPSO 

OMA 

PMA 

PMS 

POE 

RFI 

ROMC 

SAF 

SECA 

SERMIS 

SFO/EDL 

SQMD 

SSC 

SUADPS 

TO 

TIVIS 

TPS 

TYCOM 

UADPS 

VALSPECS 

VAMOSC 

VIDS 

VIDS/MAF 

XCON 

XO 


Organizational  Activity  Standard  Information  System 

Operating  Target 

Operations  Officer 

Organizational  Maintenance  Activity 

Program  Manager  Air 

Planned  Maintenance  System 

Planned  Operating  Environment 

Ready  For  Issue 

Representations,  Operations,  Memory  aids,  Control  mech¬ 
anisms 

Support  Action  Form 

Support  Equipment  Controlling  Activ  ity 

Support  Equipment  Resources  Management  Information 
System 

Summary  Filled  Order  Expenditure  Difference  Listing 
Squadron  Manning  Document 
Supply  Support  Center 

Shipboard  Uniform  Automated  Data  Processing  System 

Technical  Directive 

Type,  Model,  Scries 

Transaction  Processing  System 

Type  Commander 

Uniform  Automated  Data  Processing  System 
Validation  Specifications 

Visibility  and  Management  of  Operating  and  Support 
Costs 

Visual  Information  Display  System 

Visual  Information  Display  System  Maintenance  Action 
Form 

The  Expert  Configurer  (used  by  Digital  Equipment  Corp.) 
Executive  Officer 
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